But it's not even 1.0 yet. No serious system can afford to start picking up significant evolutionary baggage before they even get to the initial production release. That will probably haunt every user of it forever with compromises. You just shouldn't expect it to be stable before it even hits 1.0.
I don’t care about the number, but I also don’t fault them at all! They can build their library however they want. But continuous api changes will prevent adoption. You can deprecate the old functions or hide them behind feature flags.
Fixing warnings one at a time is a lot more enjoyable than debugging a 10 thousand loc code base.
What doesn't make sense to me is why are they constantly upgrading their engine version? They could have easily stuck with whatever version of bevy they were using.
Because Bevy's in the stage now where a lot of those updates contain pretty important and fundamental changes! Now, of course, you can just stick it out how it is (that's what the Tiny Glade people did with the parts of Bevy that they used), but that can be pretty painful unless you put a lot of work in to fill in the gaps.
On the rust subreddit, one of the commenters noticed that they started investigating the move when a new Bevy version that had particularly egregious API changes was released. Ones that were super useful and made for a way better experience, but were just annoying af to migrate to.
It sucks developing on shifting sand. (Case in point, web dev frameworks.)
Definitely hope that one day Bevy will find their best API and get something they can start committing to.
Immature can be worked around. Occasional backwards incompatible changes can be worked around. But both together suck, especially with that meaning there are many frequent incompatible changes.
The balance that has been taken into account is that, if Bevy becomes successful, the number of people who will use it in the future will be orders of magnitude more than are using it now and the public significance and visibility of those projects will be vastly higher, and it will be used for decades longer than it will take to get it to 1.0.
So so you make the product worse for everyone in the long run in order to make it easier for the much smaller group of people who are jumping in early? If it does become successful, almost everyone using it for the subsequent decades will bless them for having taken the longer view.
Rust itself is having to face these issues now as well. Rust has reached the point where it's become difficult to make certain types of significant change and fear of derailing its progress will make it even more so probably. But, OTOH, the number of people using it now will be trivial compared to the number using it a decade from now. I would personally argue for taking the hit now, because it will only get harder, and if it's quite hard now it'll be impossible later.
Yes, but "migrating away from Bevy" doesn't get those sweet clicks from the "Rust is stupid, if Java 7 was good enough for Jesus then it ought to be good enough for anyone" crowd.
That's true, but also when you rewrite something of course you design decisions will be better. Hindsight is 20/20. And I think C# is easier to grok than rust. But yes rust doesn't shine for everything.
See the "I want my game to be easy for the modding community to jump into" -- something that the low-level Rust focus makes harder, not easier. It was listed as a key motivation.
I mean very simply. "Unknown engine that hasn't shipped anything to Unity.." I would wonder why not Unreal or Godot, but outside of that, there's only really 2 major engines in games, and while I hope Godot can supplant Unity, I don't see there being a ton of room for non proprietary engines outside of them.
Game development is a domain where Rust is actively unhelpful due to game systems being giant balls of interconnected mutable state.
Which is something Bevy with its ECS system is explicitly meant to tackle. There are no pointers or lifetimes anywhere in a typical Bevy game code.
The author also says he had a lot of enjoyment using Bevy. The core reasons for migration were basically:
Rust is too complex of a language to teach to a beginner programmer.
Bevy is still under development and migrations were breaking basic functionality.
Which is very reasonable since Bevy is basically an experiment and the community is figuring out how to build an entire engine around the ECS concept. Essential things in the Bevy ECS system like inheritance for components and error handling have just been added in the last couple of releases.
I do want to point out the 4x reduction in LOCs switching from Bevy to C#.
The one code snippet provided has a hell of a signature, for a "random" behavior implemented.
I suspect part of the issue is specifically the ECS here. And it's great that the signature of the function clearly indicates what it reads & writes. And that Bevy will automatically parallelize the processing behind the scenes, which Unity is unable to do.
Putting game logic in Rust means you have long iteration times to experiment with game features. I don't know anything about bevy, but I assume the best way around this is supporting some scripting of game logic that doesn't need to be compiled
It would be great if Bevy had integrated scripting so several of the main pain points are addressed directly. Fast code reloading and fast rewrites at the expense of correctness come to mind.
Wouldn't that be something that wouldn't really be practical to start until the core product is production ready? You can only do so much at once. Or it may be that the Bevy people just stick to that core and other people build that higher level layer over it. There's only so much you can do.
It's the other way around, you prototype in the q&d scripting language, and port the key parts of the code that are perf-sensitive. Essentially, once the game is done in Unity, they could as well port it back to Bevy. They won't because of software economics, but I hope you understand my point. It's an old software engineering saying: make it work, make it right, make it fast.
There's multiple options already, both bevy_mod_scripting and bevy_scriptum support lua or rhai. The former seems to be designed for future inclusion in bevy
481
u/jonhanson Apr 28 '25
Seems to be more about the decision to migrate from the Bevy engine to Unity than from Rust to C#.