Leaving Rust gamedev after 3 years

> That said as a few other people pointed out, the key is iteration, hot-reload and other things. Given the choice I'd probably do(and have done) a Rust based engine core where you need performance/stability and some dynamic language on top(Lua, quickjs, etc) for actual game content.

I fully agree that this will likely be the solution a lot of people want to go with in Bevy: scripting for quick iteration, Rust for the stuff that has to be fast. (Also thank you for the kind words!)

This is how I feel about golang and systems programming. The strong concurrency primitives and language simplicity make it easier to write and reason about concurrent code. I have to maintain some low level systems in python and the language is such a worse fit for solving those problems.

I think there's a certain type of mind that can truly appreciate Rust as a language and enjoy developing with it. When I see quotes like,

> I wasn't thinking "what's the right way to get a random generator in here" or "can I assume this being single threaded" or "am I in a nested query and what if my archetypes overlap", and I also didn't get a compiler error afterwards, and I also didn't get a runtime borrow checker crash. I used a dumb language in a dumb engine and just thought about the game the whole time I was writing the code.

and,

> The prevalence of perfectionism and obsession with "the correct way" in the Rust ecosystem often makes me feel that the language attracts people who are newer to programming, and are easily impressionable.

I see someone who simply does not think about those kinds of things when writing code. And that's completely, entirely fair. Rust is not for them, then.

But they seem to act like it's an issue with the language that it does not serve them specifically, and their way of thinking in particular, not even pertaining to game development.

Because the thing is, I don't suffer from the issue they're describing. I don't find it difficult or distracting to think of edge cases and implementation details when I am writing out a solution. In fact, I can't help it. I love Rust, because its strong typing and strict static analysis actually support and justify my way of thinking. They're not obstacles for me to overcome, certainly not like how it's described here.

When I use a language like JavaScript, people tell me that I care too much about details or that I don't need static type information because I can just assume. JavaScript is not for me, because it doesn't support my way of thinking. It is terrible and sloppy and completely unchecked. It's absolutely great for banging things out without giving a care in the world about a single implementation detail that isn't relevant to the actual problem at hand. It's terrible if you actually do care about those implementation details, because nobody else who writes JavaScript does. Everything you interact with is going to be just as shoddy as the language itself.

(I have a job writing JavaScript, so this doesn't mean that I can't use the language. It just means I do not like it. I do like TypeScript.)

So this might just be a fit issue. I haven't read the rest of the article yet, because this stuck out to me. I see some other HN comments talking about async code and GUI libraries, and those are all completely valid concerns, but in the article these valid shortcomings are seemingly mixed with what I'm going to call "neurotype issues". In other words, I suppose the author just isn't autistic enough. It has nothing to do with being new to programming or not.

And that's fine. It's just not an issue with the language that it doesn't serve you as well as it serves others. After all, Haskell is the same way. I'd say most programming languages are the same way.

I don't use Rust for game dev but I do for low level libraries and find it easier than C++ to get started. I have enjoyed it more than Java and like it for different reasons than Go, but it feels good to program in.

As for the design patterns that a complex game requires, if you are considering Rust for game dev and ecs design patterns it might be useful to check out projects that are Rust centric like https://spacetimedb.com/.

> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.

But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on.

C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.