Hacker News Reader

> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.

Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.

> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal

Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are well understood.

I think this might be a case where explaining the real-world benefit instead of the theoretical benefit is needed, if only to counter what are very pointed criticisms that are definitely deeper than at the theoretical level.

Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png

You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!

The problem is that most of the gameplay code is linear, and people have already gotten good at splitting parallel work across threads. Serious physics engines (see jolt) are already designed to run on another thread and distribute the work across multiple cores. The main part of graphics drivers when using opengl or vulkan run on another thread and the UI you access just passes data to it. Rust's parallelism hasn't proven to be faster than C/C++, let alone less annoying to achieve.

Among those who have tried both, I can confidently say that the idea that C/C++ parallelism is as easy to achieve as parallelism in Rust is very much a minority view. There's a reason why nobody tried to parallelize CSS styling in a production browser before Stylo came along.

I'm talking about games specifically. I don't know much about the needs of web browsers.

I've parallelized emulators in C++ and work on parallel parts of Bevy now, which is probably the closest you're going to get to someone who has worked on parallelizing parts of large game engines in both C++ and Rust. It was far easier in Rust.

Ah, you mean specifically parallellizing a complex non-parallel system? Not designing a parallel system from scratch?

>> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal

>> Is it? The article addresses that, and basically calls it a pointless feature

> You can see that all the CPUs are being maxed out.

You're missing the forest for the trees - the poster above basically said "seeing all the CPUs being maxed out is a pointless feature" and you reply with "but see, all the CPUs are being maxed out".

You're literally ignoring the complaint and replying with marketing.

No, the original article said that you don't get parallelism from Bevy in practice:

> Unfortunately, after all the work that one has to put into ordering their systems it's not like there is going to be much left to parallelize. And in practice, what little one might gain from this will amount to parallelizing a purely data driven system that could've been done trivially with data parallelism using rayon.

It's not saying "yes, you get parallelism, but I don't need the performance"; it's claiming that in practice you don't get (system-level) parallelism at all. That's at odds with my experience.

To be fair, you've posted a toy example. Real games are often chains of dependent systems, and as complexity increases, clean threading opportunities decrease.

So, while yes it's nice in theory, in practice it often doesn't add as much performance as you'd expect.

The article is not saying that Bevy does not parallelize but that the impredictability of parallelism (both in ordering and in timing) forces the developer to add enough dependency constraints that there is not much left to parallelize.

The fact that 100% of the CPU is being used, and multiple systems are executing in parallel, shows otherwise.

Both I and the author agree with that, but it was not the point:

> the impredictability of parallelism (both in ordering and in timing) forces the developer to add [...] dependency constraints

The fact that it is possible to make a benchmark without hitting this problem does nothing to prove that bigger games can avoid it too.

Hitting 100% CPU means nothing unless those cores are doing things you actually want them to do.

That makes no difference if the game is boring.

You could say that about any game engine. Are you suggesting Bevy should try and not optimise performance because perf and fun are not correlated?

I'm saying that making it easy to experiment with different gameplay mechanics is far more important than making it the most efficient. Even more so in case of small studios.

The context of this article, and my comment, is game development. Not game performance or engine optimization, which while related seem like related but smaller aspects of the overall topic.

The way I interpret the claims is that bevy is putting far too much focus on performance and multi-threading when by far the important thing to focus on for game development is allowing the actual game developers to rapidly iterate.

Bevy might be very fast and performant, but if that seems to have come at the cost of (or been optimized for over) features that make it easier to use in ways that game developers need, then the criticism may have merit. Whether that's true or not I don't know, but hopefully that explains why a response about how it definitely can use lots of threads and make good use of many cores isn't really seen as a good rebuttal to the criticisms leveled.

It's a good feature, but still a niche one. It's a bit like choosing Unity only because of DOTS. For a few projects perhaps it make sense. But just a few ones.

Nobody said that every game needs that level of performance. But saying that it's a solution looking for a problem is not true.

I'm fully in favor of having Bevy support dynamic languages, as implemented in for example bevy_mod_scripting [1], for projects that don't need that parallel performance.

[1]: https://github.com/makspll/bevy_mod_scripting

Good scripting support is probably the way to go for Rust game development anyway in order to achieve high iteration/idea testing velocity. We could have a script engine that memory-manages various in-game objects and the scripts call into Rust functions to do the heavy lifting. Those Rust functions will typically take things by reference from the script engine so that memory-management is mostly a non-issue.

> automatically scale to multiple CPUs

We've been promised automatic CPU scaling in programming languages since at least 2001, and I've yet to see any practical version of it.

I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).

https://dioxuslabs.com/blog/release-050

Seems promising, very React-esque with little boilerplate

I hope Rust does gain mature options for its GUI ecosystem, but the author of the article makes a very good point that in other languages, there would be mature options in use already. "Seems promising" is too little, too late.

For sure! I would not write a game in Rust in 2024.

Many games are written in Rust already, but they are not AAA games. Example: https://bfnightly.bracketproductions.com/chapter_0.html

Development speed is many times lower than with Typescript frameworks, while the result is not faster or significantly more stable.

Why should anyone choose Dioxus over Sveltekit, Next or Nuxt? I never had an issue with a frontend app that the borrow checker would have catched. Error handling was an issues some years ago but is solved by now when using one of those modern frameworks. (I don't know if Dioxus has error boundaries, though.)

Those Rust fullstack frameworks make sense only for people wanting to use Rust, not for people looking for the right tool for the job.

Idk maybe when you can’t target web.

Agreed. Multiple languages exist. They can be part of {your, your team's} toolbox for different specific purposes. Some languages are set by other tools or by team members' backgrounds. Popularity also lends itself to greater availability of tools and Q&A forums. In the end, it's a better decision-making process to select what is most likely to be long-term productive for a specific project and team.

This might be controversial, but "Safety" and "Speed", in the same ecosystem, are not free. The cost is heavy syntax and heavy cognitive climbs. Why Rust was ever sold as a language for the masses is beyond me. A safe, fast, hard language is something you use for operating systems, aircraft, etc.

I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.

It's possible to write unsafe and slow code in Rust.

> Rust game development feels like a solution looking for a problem to fix.

The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.

This is not necessarily a bad thing. Especially given that Rust is an immediate upgrade with no downsides when moving away from C or C++. It is easy to see with people never wanting to go back, which also involves getting companies and products to adopt it as you would otherwise be forced by the market to work with inferior tools.

As a counterexample, .NET suffers a lot from the lack of evangelism - big chunk of community that started out back in .net framework days still thinks of it as poorly as people outside the ecosystem because they never bothered to drop old and obsolete tools and targets and give new versions a proper try (as the code is often vastly simplified and performance is vastly better).

Other programming languages, not only Rust, also do better at self promotion - take for example Go that managed to convince everyone to put it in the same bucket as Rust (which, personally, I find absolutely insulting as C# is a much closer alternative to Rust both in performance, features and access to low-level bits).

I mean, if we are allowed to lie in order to promote Rust, why don't we just smear all the C/C++ code bases in the world as security hazard needed to be sorted out ASAP?

Unless we already do...

I doubt security is the matter everyone is concerned with but rather the quality of tooling and developer experience.

It is, of course, difficult to convey to developers who only experienced C and C++ build systems, or Ruby tooling and brittleness, or Python way of managing dependencies, or setting up the packaging when using Java, that fast and easy to use solutions do not come from trade-offs but from just better ways of doing so - using cargo and Rust or dotnet and C# is night and day difference compared to options listed above.

I said it here in the past and will say it again: it's not that Rust (or .NET for that matter) are that good, it's a lot of other popular languages and platforms are that bad at one or another aspect (or many at the same time), that make it sufficiently painful to never tolerate a downgrade when you worked with a tool that offers better all-around experience.

I value good tooling as much as the next software engineer. We have good IDEs, build systems, package managers in Java and .NET lands; but we also have a decent environment of established, well-maintained libraries and frameworks.

Rust is deemed to have good tooling, but the third-party library ecosystem is following the NPM/RubyGems culture with all the fragmented dependencies, plus the added complexity of compile times due to lack of ABI compatibility.

Meanwhile, monolithic projects like Tokio also keep strengthening their reign among the small peasant crates.

I'm learning Rust, after decades of various languages with garbage collector, and I believe in the language itself and its tooling. But everything else about Rust irks me.

When single bug may cost millions of dollars, then Rust is cheaper and faster than Go. Google manager is not a liar.

Just a small addition: Godot also has great C# support. It is a real charm to work with.

The godot-rust project crates take a minor amount of adaptation to understand how it exposes the Godot object system in Rust but it's also pretty well developed.

Nice to hear! Really want to get into Rust at some point. This might be a nice segue into it

Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.

How long ago was that? I only started with the most recent version of godot and it all works as expected.

However, I am also using Rider.

Godot C# works pretty seamlessly with VSCode and has improved dramatically over the years. It did regress a bit in Godot 4 after swapping to the newer .net "core" (in terms of platform support) but as of 4.2 I have had no issues at all.

We're doing more and more of our back-end work with Rust. The main reason is the performance it provides. It's not just great for our end-users it's also so much cheaper in the modern world where we pay per mileage in the cloud. Part of what we really like about Rust, however, is actually exactly the variable ownership because it makes it very straight forward to enforce and control data-integrity and avoid race conditions. Even for programmers who would struggle to do so in C or C++.

I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires.

> my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust

Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.

> C/C++

is not something that exists in the real world.

Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization.

* name intentionally made to make people angry

If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.

I would assume that it would opportunistically try to run the borrow checker, and if it fails on the access of a specific field, turn that access into an Arc/Rc everywhere, leaving any other access as references. This leaves you with invisible performance cliffs, where accessing a field in a new place suddenly increases the cost of accessing it everywhere else, but it does give you the "just do what I want, damn it!" development experience. I doubt Rust itself could do that without alienating its current userbase, but a RustScript could.

Thanks for the reply, it's an interesting idea.

There’s [Rune](https://github.com/rune-rs/rune/).

Rust ain't Go but anything Go has can be used as an argument that Rust should try to do better in certain areas. ;)

Perhaps learn another language like Haskell, Swift, or Kotlin before Rust.

Get cargo-bloat, cargo-cache, and cargo-outdated.

Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location.

Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.

> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial.

So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?

Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?

> So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?

Memory safety and memory management are different things. Scripting languages remove the burden of manual memory management; as a side effect, they also tend to be memory safe, but that hasn't been the main motivation.

As I said in my own comment down thread, despite being a huge rust advocate, I sincerely agree with you here.

Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful.

This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development.

I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.

But people want to write Rust and a game seems like a fun way to do it. They can already use Godot or Unity with this approach.

Garbage collection causes performance issues.