Highlights from the comments on “Migrating away from Rust.”

Original Post: Migrating away from Rust.

Thanks to everyone who read and commented on this post.

Much to our surprise, the post was #1 on HackerNews and floated in the top 10 for about 24 hours, more importantly, we were thrilled by the degree of positivity expressed by the community as well as the depth of the conversation that followed.

The post resulted in around 150,000 page views in the first day and we also saw interesting conversation on reddit and the Bevy Discord.

I can’t possibly respond to, or cover, everything that was said, but we wanted to share some insights from the discussion and focus on a few recurring themes.

Rust's Place in Game Development

jonhanson writes:

Seems to be more about the decision to migrate from the Bevy engine to Unity than from Rust to C#.

We saw this comment in a few places. This is fair and highlights an important nuance. The original post emphasized problems sourced in the structure and development methodology of Bevy (API churn, regressions) while other issues were due to Rust itself. This comment and many others underscored how intertwined the language and engine can become, making them hard to evaluate in isolation.

Unity is a C++/C# engine. Unreal is a C++ engine. Bevy is a Rust engine. When you choose to adopt one, you adopt the other and while you may have an option for a high-level scripting language, you are still going to find some amount of development time spent in the underlying implementation language (when debugging, for example).

palata writes:

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++.  But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either.

palata’s comment sparked a long thread on Hacker News about the trade-offs between a language’s performance, expressiveness, and implementation efficiency. There is no correct answer, but we have come to value increased productivity over other considerations. Many commentators observe that you should also build software in the language you enjoy, but there’s a clear balance that must be maintained between personal objectives and pragmatism.

Another aspect of palata’s comment is that Rust is a fun, powerful language and a competitive choice in its class of low-level systems languages. It’s only limited by the fact that its class may not be the best fit for most game development projects and teams.

ryanisnan writes:

When it comes to projects like these, efficiency is almost everything. Speaking about my own experiences, when I hit a snag in productivity in a project like this, it's almost always a death-knell.

Related to productivity is the theme of tempo and consistency. Structural language benefits like correctness and memory safety have value, but that value is eroded if language structure stands in the way of the fluid implementation of gameplay ideas. For us, Rust's compile-time friction and Bevy's API churn interrupted the rapid mechanic-prototype loop that we needed to land the plane. Whether or not that is a problem for a project will depend on that project's type, scope, and team’s specific needs.

You Have to Churn to Make Butter

Another thread of debate was the trade-off between progress and change.

IronGremlin, on Bevy discord, writes:

Breaking changes every 6 months or sooner is rough as a cadence for a decently sized project, and it kind of gets worse in some ways when the stuff being added is like fundamental building blocks you feel you’ve needed for months (or longer).

This mirrors our experience. In case the original post sounded too much like griping about Bevy’s rate of change, let us be clear: each Bevy update brings a huge slate of improvements and useful features. When asked why we don’t pin to a specific version of Bevy, my answer is because then we wouldn’t be leveraging all the work of its excellent community.

There is an element of personal discipline in choosing when to migrate to a new version, but with Bevy the marginal value of each update is very high. It’s very likely that an update will bring a feature that either enhances or solves a chunk of work you planned to do.

So again, trade-offs. For our project and our needs the costs that came with these updates were more expensive than the benefits and so we sought a kind of shelter in the relative stability of a less mutable project.

It's important to highlight the strong arguments made in favor of Bevy's current trajectory and viability, especially from those deeply involved in the ecosystem.

pcwalton writes:

Using Bevy isn't writing your own game engine. Bevy is 400k lines of code that does quite a lot. Using Bevy right now is more like taking a game engine and filling in some missing bits. While this is significantly more effort than using Unity, it's an order of magnitude less work than writing your own game engine from scratch.

Over the past year I've been working at my studio to add enough features to Bevy to ship real apps, and Bevy is at the point where one can reasonably do that, depending on your needs.

pcwalton has been a key contributor to Bevy, carrying a lot of water for the engine’s 3D rendering tech. His views are worth listening to, as a qualified domain expert.

ChadNauseam writes:

This is highly annoying, no doubt, but the API now is just so much better than it used to be. Keeping backwards compatibility is valuable once a product is mature, but like how you need to be able to iterate on your game, game engine developers need to be able to iterate on their engine. I admit that this is a debuff to the experience of using Bevy, but it also means that the API can actually get better (unlike Unity which is filled with historical baggage, like the Text component).

Bevy is getting better fast and to their credit, the Bevy team is unwilling to carry bad API and design decisions into the future. They aggressively review their own decisions and make alterations that larger engines can’t afford to make.

We see our migration to Unity as a project-specific call, not a universal prescription. A case can be made that a certain type of project and team could absolutely ship something excellent in Bevy.

AI's Role in the Decision

Sachymetsu, on Bevy discord, writes:

This AI nonesense is going to be such a pain for anything new trying to emerge and establish itself though. If people rely on it too much, there’s no point in trying new things which won’t be as supported by these tools.

Similar concerns were echoed on Hacker News and Reddit.

This could be a short term growing pain. Future AI tools are likely going to be better at drawing advice from the most recent set of documentation and we might expect future doc authors to write with AI in mind. We might even expect fine-tuned models to replace static doc-gen at some point.

On the other hand, there isn’t really any immediate replacement for the multitude of tips and tricks that an engine’s community accrues after many years of use and older engines will always have the advantage of familiarity. LLMs concentrate this advantage, stripping away the effort of having to search through decades of forum posts for the commonly accepted answer to an implementation problem.

Where these forces end in equilibrium remains to be seen, but we would guess that LLMs will mostly energize innovation in game and engine design as a general side effect of increasing productivity.

dagw writes:

Almost every time I've run into similar problems with LLMs I've mostly managed to solve them by uploading the documentation to the version of the library I'm using to the LLM and instructing it do use that documentation when answering questions about the library.

It is very possible that this is a skill issue and if we spent more time focusing the model on what we needed we would have had less of a problem with confused replies.

Not Hard Enough on Unity

A number of comments suggested we weren't hard enough on Unity. To some extent, this was a content decision about where to focus the post.

JoshValijosh, also on Discord, wrote:

Unity absolutely loves to break in inexplicable ways for me. The source code for Unity, Unreal, and Godot are 100% black boxes to me, but when something breaks in my bevy project, I just go fix it. […] Part of my reason for using Bevy is because I’ve blown what feels like hundreds of hours trying to fight Unity through some cursed failure mode that nobody knows how to fix.

We expect Unity to come with flaws and migration between major versions to require a lot of effort for questionable returns. We also expect to not need those migrations. Unity is fully featured in its current form and so we expect the marginal value of updates to be lower and a lot less necessary.

Unreal’s source code is publicly available, but Unity’s is not, so the point about bug fixing is well taken. We’re placing a bet that access to the underlying source isn’t going to be the necessity it is with Bevy. We could be wrong, but Unity has a kind of existence-proof here with all of the games that have successfully shipped under its banner.

I fully plan to write tech posts about Unity as we implement features and run into problems.

Conclusion

We want to thank everyone who shared their insights and experiences and everyone who spent time to read the original post. It's clear that engine and language tech choices involve complex trade-offs that strike at the heart of why we choose to spend so much time building games.

While we think we made the right decision for Architect of Ruin, we continue to have immense respect for the work being done in the Rust and Bevy ecosystems. Our attention will now turn to building gameplay and we look forward to sharing more of that journey.

Stay in the Loop 🗡️ If you’ve read this far and want to watch our sword-and-sorcery colony grow, join the newsletter to get dev updates & first-look builds.