It's already happened, but obviously it's easy to miss since by definition you're looking for submission titles that don't mention Rust. It feels like nearly every day this week has had a Rust project on the front page of HN without a mention of Rust in the title.
Here to verify, there's a fair bit of software where the state of the art is in Rust. How it happened so quick is a little surprising, but here we are.
Hasn't this already already happened though? There's literally nothing else that can compete with ripgrep.
A project using Rust isn't a good enough selling point to me if the tool doesn't do what I want, but more often than not I find Rust projects have a level of quality far exceeding C & C++ projects.
Vaultwarden is a great example. Though admittedly, it was originally named Bitwarden_RS, it's now a fully-featured Bitwarden clone that's hailed as vastly easier to run and administrate than the full heavy official Bitwarden server.
When I first wanted to self host Bitwarden, I saw the gigantic setup from the official site and thought "oh shit", then gave up for some time.
A friend mentioned bitwarden_rs and after 10 min I was done.
I think that at this point Bitwarden should advertise it as the official way to self host (after reviewing the code) taken the adoption and stability. I use it for a year or so and it never failed, backup is ready etc.
A generic framework that others can use to build their own Minecraft server sounds more fruitful and less prone to fragmentation than three projects doing the exact same thing with different goals.
Whenever I see "... in Rust" because it is such a popular for hobby projects that are prone to being abandoned. Of course, that might happen to any project in any language, but something tells me that if you manage to get a C codebase to a functional and maintainable point, there is already some energy behind the initiative. There are counter-examples (first and foremost Ripgrep), but I have become so prejudiced in this matter that I'm always skeptical until proven otherwise.
The insight contributors chart is usually a good clue. It’s not perfect because it only shows the main branch configured in GitHub and some project haven’t merged to main in years.
Still, it’s good to see how many big contributors a project has, and how active they are over time.
I'm not big on Minecraft, but because my kids enjoy it, I run a few instances of the official server.jar. Even on a fairly beefy shared-use server (on which I do some development with a friend), MC can get pretty choppy, which really surprises me. I should try out Feather to see if it can handle the load better.
If you want a recent and feature complete server that performs better than the official one check out PaperMC. That's basically the de-facto standard for servers these days anyway.
It's better but still fairly resource-intensive. I'm wondering why it's so as the main work is being in the client, whereas the server concentrates on updating the structures close to the player - the rest of the universe is either generated or loaded on the fly. I'm fairly sure this could be optimized much more.
>Our mid-term goal is to make Feather usable on hub and minigame servers. The limited set of gameplay features available in Feather is not a problem for such servers that require a small subset of vanilla functionality.
"Minigame server" is self-explanitory, given the existence of Roblox, but what's a "hub server"? I'd guess something like the difficulty/world selectors in Quake 1, but for other Minecraft servers that the client then connects to?
I read quite a bit of the Minecraft source but I am by no means an expert. Based on this I would guess the hard part is implementing the actual game logic as Minecraft runs some game logic on the client and some on the server. And much of it has all kinds of weird behaviors depending on whether the outer loop for some logic is along the X and the inner loop along the Z direction or vice versa and things like that. Without decompiling and deobfuscating the game you will never get this to work correctly.
It's pretty shitty, at least 8 or so years ago. Not sure about the current state. Back then it had, for example, no length information in the header (so you always have to parse it completely and cannot skip any packet), shifted packet ids around for new releases and had a pretty odd mix of data types.
It'll happen eventually I hope. Rust itself is indeed a fantastic language.