The problem with Rust is that almost everything is still at an alpha stage. The vast majority of crates are at version 0.x and are eventually abandoned, replaced, or subject to constant breaking changes
While the language itself is great and stable, the ecosystem is not, and reverting to more conservative options is often the most reasonable choice, especially for long-term projects.
I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great.
But outside of games the situation looks very different. “Almost everything” is just not at all accurate. There are tons of very stable and productive ecosystems in Rust.
> I really don’t think Rust is a good match for game dev. Both because of the borrow checker which requires a lot of handles instead of pointers and because compile times are just not great.
I completely disagree, having been doing game dev in Rust for well over a year at this point. I've been extremely productive in Bevy, because of the ECS. And Unity compile times are pretty much just as bad (it's true, if you actually measure how long that dreaded "Reloading Domain" screen takes).
"ECS" == Entity-Component-System, "a software architectural pattern commonly used in game development and other simulations for organizing game objects and their data," according to Google Gemini.
Borrow checker is mostly a strawman for this discussion, the post is about using Bevy as an engine and Bevy uses an ECS than manages the lifetime of objects for you automatically. You will never have an issue with the borrow checker when using Bevy, not even once.
Everything in every ECS system is done with handles, but the parent comment is correct that many games use hairballs of pointers all over the place (and they are handles with ECS). There is never a borrow checker issue with handles since they divorce the concept of a pointer from the concept of ownership.
The main feature of rust isn't borrow checking, the feature is safe low level programming. Borrow checking is Rust's default way of doing this, but it's not the only one (the standard library has Reference Counting primitives built in).
Borrow checking is a way to make manual memory management safe, ECS works around manual memory management entirely, so it doesn't need borrow checking to be safe (which is also why it's popular in C++, which doesn't have a borrow checker) but because it's Rust, you have strong guarantees about the safety of it, while in C++ you can still shoot yourself in the foot if you don't use ECS the right way.
I would argue that borrow checking is the only feature that is actually unique (more or less) to Rust. If you don't need it, you can get the rest from elsewhere, often with better ergonomics.
If you want to squeeze the maximum performance of your hardware (which is indeed the case for game engines) then all your options are Rust, C and C++. In which case is by far the more ergonomic choice on every aspects.
You could add a lot of research/experimental and/or legacy languages as well (Modula 3, Odin, D, why not FORTRAN, even) but none of them are credible alternatives to C or C++ like Rust has managed to become. And none of them are polished enough (be it in terms of errors messages, libraries, docs, onboarding material, build toolchain) to be considered superior to Rust in terms of developer ergonomics even if you set aside safety.
And again, borrow checking isn't a feature, it's an implementation of the feature which is memory safety without performance tradeoff. Even when using a paradigm that doesn't interact with the borrow checker, you're still using the feature itself (especially because all of the underlying building blocks which aren't using ECS directly are benefiting from the borrow checker's validation).
I wouldn't say 'almost everything', but there are some areas which require a huge amount of time and effort to build a mature solution for, UI and game engines being one, where there are still big gaps.
> The problem with Rust is that almost everything is still at an alpha stage.
Replace Rust with Bevy and language with framework, you might have a point. Bevy is still in alpha, it's lacking plenty of things, mainly UI and an easy way to have mods.
As for almost everything is at an alpha stage, yeah. Welcome to OSS + SemVer. Moving to 1.x makes a critical statement. It's ready for wider use, and now we take backwards compatibility seriously.
But hurray! Commercial interest won again, and now you have to change engines again, once the Unity Overlords decide to go full Shittification on your poorly paying ass.
Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects. Rust language and library features themselves often spend years in nightly before making it to a release build.
You can also always go from 1.0 to 2.0 if you want to make breaking changes.
> Unfortunately, it is a failing of many projects in the Rust sphere that they spend quite a lot longer in 0.x than other projects
Yes. Because it makes a promise about backwards compatibility.
> Rust language and library features themselves often spend years in nightly before making it to a release build.
So did Java's. And I Rust probably has a fraction of its budget.
In defense of long nightly feature more than once, stabilizing some feature like negative impl and never types early would have caused huge backwards breaking changes.
> You can also always go from 1.0 to 2.0 if you want to make breaking changes.
Yeah, just like Python!
And split the community and double your maintenance burden. Or just pretend 2.0 is 1.1 and have the downstream enjoy the pain of migration.
> And split the community and double your maintenance burden.
If you choose to support 1.0 sure. But you don't have to. Overall I find that the Rust community is way too leery of going to 1.0. It doesn't have to be as big a burden as they make it out to be, that is something that comes down to how you handle it.
Godot launched 0.1 in February 2014 and got to 1.0 in December 2014.
The distance in time between the launches of Unreal Engine 4 and Unreal Engine 5 was 8 years (April 2014 to April 2022). Unreal Engine 5 development started in May 2020 and had an early access release in May 2021.
Bevy launched 0.1 in 2020 and is at 0.16 now in 2025. 5 years later and no 1.0 in sight.
If you want people to use your OSS projects (maybe you don't), you have to accept that perfect is the enemy of good.
At this point, regulators and legislators are trying to force people to use the Rust ecosystem - if you want a non-GC language that is "memory safe," it's pretty much the de facto choice. It is long past time for the ecosystem to grow up.
> Godot has been an in-house engine for a long time and the priority of new features were always linked to what was needed for each game and the priorities of our clients.
I checked the history and it was known by another name Larvita.
> If you want people to use your OSS project
Seeing how currently I have about 0.1 parts of me working on it, no I don't want to give people false sense of security.
> At this point, regulators and legislators are trying to force people to use the Rust ecosystem
Not ecosystem. Language. Ecosystem is a plus.
Further more the issue Bevy has is more of there aren't any good mature GUI libraries for Rust. Because cross OS GUIs were, are and will be a shit show.
Granted it's a shit show that can be directed with enough money.
I don't even look at crate versions but the stuff works, very well. The resulting code is stable, robust and the crates save an inordinate amount of development time. It's like lego for high end, high performance code.
With Rust and the crates you can build actual, useful stuff very quickly. Hit a bug in a crate or have missing functionality? contribute.
Software is something that is almost always a work in progress and almost never perfect, and done. It's something you live with. Try any of this in C or C++.
Well, on the flip side with C++ some of it hasn't been updated beyond very basic maintenance and you can't even understand the code if you are just familiar with more modern C++…
While the language itself is great and stable, the ecosystem is not, and reverting to more conservative options is often the most reasonable choice, especially for long-term projects.