Re-implement masterserver in Rust
Rust has some advantages that might be useful for us in regards of the implemention of a game server:
- Safety against Null pointers, race conditions and all sorts of low-level threats.
- Predictable runtime behavior (zero cost abstractions and no garbage collector).
- (Almost) total control over the hardware (memory layout, processor features).
- Seamless interoperability with other languages ( C interop and FFI)
- Incredible runtime speed (comparable with C/C++)
- Simple package management with cargo
- Support for Generics in form of traits
An example of a game server implementation you'll find here: Game Server in 150 lines of Rust
What are your thoughts about this? Would you prefer also Rust for a re-implementation?
@simonsan The goal of this issue is for a reimplementation of the master server or the game server? I believe they are two different things, and the current project is aimed at building a master server only? Other than that, Haskell is doing pretty well on every point you dropped (perhaps except on the memory side if you don't know what you are doing), as well as being the complete opposite of Go (the link you provided is comparing Rust against Go).
@nerded1337 Hey, you're right. This repo is for the master server only. But we probably have to update the docs here a little bit because they are a bit outdated :smile: The current architecture idea can be found in this gist
Quick summary:
- The master server(s) is/are used as a public registry for dedicated servers and to connect players
- Community organisations can run their own matchmaking, account services, ladders and so on. They technically don't need the master server, but can register their servers there.
- Game servers can be run by anyone, whether it be community organisation or someone with a basement.
The old approach was to use Haskell, but we have not yet decided if we will reimplement it in another language, once we get back to it.
@heinezen Thanks a lot for the clarifications!
Regarding Haskell I found a good recent comment from the maintainer of AURA (Package Manage for Arch Linux and the AUR) that will reimplement it in Rust for some reasoning that should be considered here as well:
-
More opportunity for outside contributions: There are simply more Rust devs than Haskell devs.
-
Better performance, smaller binaries, and static linking.
-
Official ecosystem support for release candidates. Overall easier to distribute.
-
The ecosystem has much more momentum and will likely suffer less bitrot.
-
Builds on more platforms/architectures (re: e.g. Macbooks will soon be using ARM chips. + Raspi, Related stack issue).
-
Error handling would be more straight-forward (re: IO exceptions in Haskell).
-
Can get rid of the excess config.
And last but not least:

src.: https://users.rust-lang.org/t/proposal-arch-linux-port-aura-to-rust/50592
@simonsan you are right, the first point being probably one of the most important for oss...