JorelAli
commented
5 years ago Given the current state of the project, there are a few points of consideration that have to be taken into account. These points are as shown below.
Performance
The planned release of the CommandAPI version 2.0 is designed with performance in mind. By preparing to support multiple versions of Minecraft, it was imperative that removing reflection in order to greatly improve performance was required. With an implementation of the CommandAPI that uses the Rust programming language, in order to interact with the Java based servers that the CommandAPI is designed to run on (primarily, Spigot and other Bukkit-based servers), use of system calls would be required in order to interact with compiled Rust code. This would normally be implemented using some form of the Java Native Interface (JNI), which is known for being very performance heavy and having lots of overhead.
The CommandAPI works by "injecting" lots of code into vanilla Minecraft's server at runtime, prior to and after vanilla commands have been registered. This procedure is already very intensive as is and it is crucial that the CommandAPI is as efficient as possible for the startup of a server where the CommandAPI's primary function takes place. Therefore, the use of JNI calls with its additional performance impact makes it unsuitable to use system calls.
Building environment
In order to make the CommandAPI accessible for all developers that may want to create a pull request or add new features, it must be easy for developers to build the CommandAPI. Currently, due to the planned release of version 2.0, the build requirements for the CommandAPI are already very high due to legal reasons, and thus are not very straight forward as it is currently. (Currently, for each version of Minecraft that the CommandAPI supports, a developer has to build a copy of the Minecraft server.jar in order to compile the CommandAPI). In addition, the maven dependency manager is used to help build the entire project (despite having additional build requirements), which makes building the project straight forward once the required dependencies are provided.
Adding support for the Rust programming language would make such a feat of a simple-to-build environment near impossible - requiring a custom build script would be a necessity. The CommandAPI aims to be suitable for developers on all operating systems and since Rust compiles down to a system-level file (i.e. an executable which is system dependent), this is unsuitable for the developers that use the CommandAPI.
A lightweight API
The CommandAPI is designed to be as lightweight as possible. It does not shade other projects into itself and assumes that the requirements for execution are present (which they normally are for a Minecraft server running on version 1.13.2 or above). In order to create an implementation of the CommandAPI that is compatible with Rust by using the JNI, the JNI crate would be a necessity and would be required in order to execute the code in Rust.
Interacting with the Bukkit API
The CommandAPI, like any plugin, requires interaction with the Bukkit API in order to register commands, create and read config files in the correct directory and retrieve the name of CraftBukkit's current package which is loaded in the JVM at runtime. Since Java is the language that the Bukkit API is written in, it makes sense to use Java to interact with the Bukkit API, as opposed to creating a wrapper for the Bukkit API in Rust which would create additional overhead.
If it were possible to create a system where a developer can write Rust code as an implementation for a command, since the CommandAPI does not calculate and store the parsed results in order for optimization (The removal of reflection greatly improves performance, so storing parsed results may not be necessary), the overhead can cause delays and instability with the running of the server if many commands are executed in quick succession (especially due to the implementation of Minecraft's command blocks which can execute a sequence of commands in a single tick).
Considering that the CommandAPI is an API for developers to use on servers which primarily are powered by Java, and the reasons stated above, I do not believe that it would be a good idea to implement the CommandAPI in the Rust programming language.
Since Rust is the objectively best language, I highly recommend that you re-write the project in it. In fact, I demand (for the sake of me and my fellow rustaceans) a Rust re-write. Benefits include:
Personally I believe this change is in your best interest. I look forward to when this suggestion gets accepted. :slightly_smiling_face:
PS: This is an extremely serious request, please don't mistake it for satire