Leaving Rust gamedev after 3 years

TLDR: "I picked a systems programming language to write and iterate on a bunch of gameplay scripting. Why does Rust not meet the needs of a gameplay scripting language like <every link in the article which either refers to dedicated game-programming scripting languages, or Unity which is whole goddamn commercial game engine>. Hmm yes, the problem must lie with Rust, not with the choices I made in my project."

Just try to write a complete game with nothing but open source libraries in C++, or C#, or Java. Good luck with that. The author is switching to Unity for a very good reason. It turns out a commercial product made by 6000 people delivers value...

You use a systems programming language to write your engine. And then a scripting language to write your game. Everybody in gamedev knows this, I thought.

It's not that the author picked Rust for scripting. All Rust game engines (e.g. Bevy) use Rust as the scripting language.

Compare this with Godot, which is implemented in C++, but supports GDScript and many other languages for scripting.

Also, only supporting Rust is not considered a limitation, but a feature here. Bevy's ECS is tied up with Rust's trait system, therefore it's impossible to use a different language.

So if Rust as a system programming language should not be used for game scripting, then projects like Bevy are fundamentally flawed. The author is willing to go there, but I don't know if many people would go that far.

There could be a Godot-like engine written in Rust that supports easier scripting languages, but I think that space is not explored due to the fact that Godot already exists.
- It's also worth noting that before bevy, there was a rust game engine called Amethyst, which was planning on using a scripting language for gameplay code. Not having to use a scripting language, but getting to use rust instead, was one of the big selling points of Bevy overr Amethyst.
- Completely agree with all those points.
  
  The author seems to be a enthusiastic coder and made several game engines in Rust. I'm not sure why they didn't hook up some hot-reloadable scripting to their engine, call it good, and build games. Probably less work than writing this very long article :)
  
  Yeah I would probably not use Bevy either if the only option is to write all gameplay code in Rust. It doesn't seem like the best tool for the job.
- Bevy's ECS is tied up with Rust's trait system, therefore it's impossible to use a different language.
  
  Bevy has added runtime-defined systems and components to enable scripting integration in recent updates.
As a software engineer who has worked in games, I disagree with you. Using a systems programming language like C, C++,Java or C# would all be much better for writing games from scratch than Rust. Rust really does have some unique issues. It's still a great language, just bad for quick iteration
- I’ll grant C# is easier to iterate with. But C/C++, i don’t think so. You still have to carefully consider ownership with those, just like Rust, and refactoring can be laborious. Except with Rust once it compiles your code is probably correct, ownership-wise, which iterates considerably faster than running C++ code and getting segfaults (or data races)…
  
  I helped ship multiple games. All of them used scripting languages, like Lua or in-house, for gameplay code. It makes sense for iteration.
  
  Oh and C# and Java come at a cost, of course. It’s easy to write them, I’m a big fan of C#’s design, but its overuse is also how we ended up with so many relatively simple indie games which consume gigabytes of memory and constantly drop frames stalling for GC. Nothing is without tradeoffs.
Yup, that was my impression as well.

Write the part you're interested in, and find a solid project to handle the rest. If your want to write a game, use a popular game engine. If you want to write a game engine, use a popular scripting language to test it out. And so on.

That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". This is not just with Rust, if you try using ECS you're told the same thing. If you try to use Bevy you'll be told the same thing. If you try to make GUIs with whichever framework you choose (be it one of the reactive solutions or immediate mode), you'll be told the same thing. The problem you're having is only a problem because you haven't tried hard enough.

Ugh, I hate this attitude in the Rust community. It's the elitist neckbeard attitude the early linux forums were known for that's still present in places like the Arch community.

The best advice I read about these places is to avoid them and just do stuff that works. Writing Haskell and don't want to worry about whatever highbrow computer science gatekeeping concepts? Use the beautiful escape hatch to imperative programming: monads. do { blablabla }. Is the Rust borrow checker complaining about ownership? A quick .clone() to a new variable will probably shut it up and allow you to move on. "Ermagerd, scripts should be in bash and only readable to you!", a quick ruby or python script should solve that for you. "systemd is -", just stop reading there and keep using systemd. It does the job.

This is where experienced people will often say that this becomes less of an issue once you get better at the language. My take is, while that is 100% true, there's a fundamental problem of games being complex state machines where requirements change all the time.

This is probably the best argument in the article. Rust is probably great for systems that don't have a lot of changing requirements, but fast iteration and big changes probably aren't its strong suit. I've found that planning a project ahead of time has reduced the amount of refactoring needed regardless of language, but that's because I was solving a static problem and thinking of a little bit of flexibility towards other features. Games probably aren't like that.

No language fits every usecase and it's completely find for it not to fit this dude's flow of writing games nor the types of games he's writing. It's a good thing he came to the conclusion sooner than later.

Anti Commercial-AI license

Rust is probably great for systems that don't have a lot of changing requirements, but fast iteration and big changes probably aren't its strong suit.

I agreed up until this. Fearless refactoring is a huge benefit of Rust. If the type system of another language allows the refactoring more easily without as many compilation failures, it will probably surface more runtime bugs.
- Fearless refactoring is a huge benefit of Rust.
  
  That's not the issue. The issue is the borrow checker making things slower to write. Changing requirements isn't just moving code back and forth, it's changing the existing code, moving it around, adding new dependencies, using existing code in a new way, and so on. Not easy to do if the borrow checker is screaming at you about some moved ownership.
  That's what dynamically typed languages are good at: pass in a dict/object/hashmap/whatever with some attributes to test something out, pass that around, transform it, add keys/fields, extract parts of it, transform them and return those, etc., see that it's working, and then you refactor it with proper typing, linting, and tests where a borrow checker is very very welcome.
  
  Anti Commercial-AI license
- I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it's a change to ownership.
  
  Refactoring in languages like Java and C# is effortless in comparison, and not error prone at all in a modern codebase.
  
  You can use RC and clone everywhere, but now your code is unreadable, slow, and might even have memory leaks.
  
  You can use slotmaps everywhere, but now you're embedding a different memory model with verbose syntax that doesn't even have first-class references.
  
  I don't even dislike Rust; I recently chose it for another project. I just think it has clear weaknesses and this is one of them.
- I think you're wrong. But this is clearly an article of faith amongst rust developers
It’s the elitist neckbeard attitude the early linux forums were known for that’s still present in places like the Arch community.

LMAO

Interesting to read about how borrow checker constraints affect iteration speed in game dev

Yeah seems like the wrong choice overall. I think Rust found its way to the niche of being a "new C" that's pretty much just for when you need something very optimized like kernel modules and backend hotpaths (and Firefox I guess). That's a cool niche to fill

I most enjoy Go for servers, and JS unfortunately is mandatory for many things. I don't tend to write code that requires Rust's performance. For mobile, the Flutter stack with Dart is pretty cool. For automation & simple cli, shell scripts suit me fine (but any language can do this ok). Python is tragic, Java is evil, C# is MS Java, node/npm are a toxic hazard, and webassembly with preloaded runtimes in browsers cant come soon enough

Well, the alternative to "Rust" here is not another programming language, but rather another game engine.

Because ultimately, most game engines will be implemented in either C++ or Rust, for performance reasons, and C++ itself isn't terribly better at iteration speed than Rust.

The C++ engines have simply already invested decades into abstractions, like an ECS architecture, higher-level APIs and scripting languages. There's nothing inherent to Rust which prevents these abstractions from being built into game engines, it just hasn't been around for that long.
- Well, generously I think this guys point is that you shouldn't use rust for developing actual game logic (you'd use those higher level scripts). For game logic, it's bad bc it's not very iterative - and the rest of the stack sucks too but everyone knew that getting into it. But yes, I'm sure you could make a game engine with it
IDK, I wrote Go for years (from 1.0 up to 1.16 or so) and just got tired of all the footguns. So I write in Python for things that don't need to be fast, and Rust for things that do.

Some criticisms of Go:

minimal protection for concurrent memory writes, and no protection for reads - big article about data races - these are largely caught by the Rust compiler in safe code

mediocre scope guards - it just has defer(), which is nice, but I much prefer Rust's Mutex<T> to Go's defer m.Unlock()

nil instead of monadic Result - even worse, (*int)(nil) == nil but interface{}((*int)(nil)) != nil - so checking for nil isn't even always what you expect

Each of these has bitten me and cost me hours of debugging each time it happens, and it usually only happens in production or under heavy internal testing before a release.

I went into Go expecting it to deliver more than it does, probably because of the marketing. I thought it had safe concurrency, but it really just has memory safety (i.e. it'll panic() instead of accessing invalid memory, but doesn't protect against wrong but not invalid memory access). Each time I learned something odd about it, I just gave it a pass because goroutines are so nice (they still are), but after almost 10 years of writing in Go, I've decided it's just not worth it.

Yes, Rust has a bit of friction with the compiler, but that's getting better with every release, and I can attest that after working with it for a few weeks, you learn to write code that avoids compiler fails more often than not. I use it for most of my personal projects (currently writing a p2p app with lots of async code), and it's a great tool. I still use Python for scripts and one-off projects (and my day job, which has lots of microservices), but Rust is my favorite.

Go is nice, provided you strictly follow conventions, but I don't think it works as well for larger projects, because you will run into those footguns. Maybe it won't be you, but someone in your team will do something stupid and you'll spend hours or maybe days debugging it.
- I like go in general but I agree, it's probably oversold. For me it's a pragmatic language and I like it but there's some real defensiveness about its shortcomings. In which regard , the go community has a lot in common with the rust community.
- I'm still in my honeymoon-ignoring-footguns phase with go, but am well aware I'm on the same path. I do really love how quick is it to generate a static binary that will always work.
I started with Rust but now it's also all Go for backend. I'm just not smart enough for Rust. It's too much to think about that has nothing to do with what my program is trying to solve.

That being said, Rust is superior in many ways if you can handle the effort of writing it.
- Yeah idk Rust seems superior in the less useful ways. Go's tooling, fast build times, hyper efficient parallel GC (not kidding, it's world class), interfaces, and simplicity are really killer features. Though honestly, even after many years, channels still confuse me - it's like plumbing, but plumbing needs pressure gauges, emergency valves, and buffers - so it always ends up with this string cheese of events spread over multiple files. I end up using a mutex half the time
What makes Python tragic?
Python is tragic? Why?
Java and python are great languages.

By this article it sounds like Rust is a case of “perfect is the enemy of good”.

eh, I'd say rust's problem is more that it's marketed as a general-purpose language, when in reality it is rare for software to need a language that is both very highly performant and memory safe, and rust makes heavy sacrifices in terms of complexity to achieve that. Most popular languages are garbage collected which can cause performance problems, but makes code much simpler to read and write.
- It is a general purpose language for me. I wrote lots of little (or not so little) scripts in Rust. I wrote high performance GPU kernels in Rust. I wrote web services in Rust. It's less hard to read and write Rust than is often claimed. Imo.
- I don't think there's a problem whatsoever. Rust just isn't a great choice for projects that need to iterate quickly. People online claiming that's not the case doesn't change that fact.
  
  If you need fast iteration time and can sacrifice memory safety, use a scripting language. I like using Lua within Rust for this reason, I can iterate quickly and move expensive logic that's not going to change much to a Rust lib.
  
  OP should've known this, they had experience already writing games, they just ignored the truth because some neck beards told them to. It's okay to ignore people on the Internet when they're wrong.

The hacker news comments are as usual very good too

lol

Lols what... :) Maybe it's just me but I like them. :)

I'm only saying this because I've seen this posted on several boards , and there's to much negative attitude towards the blogger.

I don't understand people being defensive, it's not like the author hates rust, as a matter of fact he loves rust and chose to write a game in it for 3 years. He's just sharing his experience with the language, and some one might find it useful, even the language devs might appreciate feedback from the community.

How is the language going to improve, if all we do I show hostility towards those who critiques some parts of the language, it's going to be C++ all over again, if people stop doing that because being afraid of getting community backlash. The elitist attitude isn't helpful and has never been.

Damn, the author sure knows how to ramble. No wonder they can't make a game with Rust, they're too busy talking about making a game.

If you're going to actually give a useful critique, organize your thoughts into a succinct narrative instead of making a giant list of rambling bullet points.

Thank you for your comments. They were actually more sane than most.

The absolutely unnecessary mini-freakouts that happen every time someone rambles like this never ceases to amuse. Some gems always surface from them though, so it's all good.

The best part of this storm in a teacup is that it came from the industry where the ratio of estimated self-importance to the real relevance of what they do reaches infinity. It doesn't get better than that.

I would like to extend my welcome to all the readers and commentators who are not !rust@programming.dev regulars. Please remember to subscribe before leaving this thread. Thank you.

So... dev blames skill issues on language? Classic.

EDIT: For the record, I'm not saying the author is bad at Rust. I'm saying they're bad at making games and balancing tradeoffs. They keep saying that they don't like rust because they just want to worry about making a game, not fighting the language. And yet, they seem to continually make decisions that favor performance over ergonomics. Then they whine about how the Rust community is supposedly pressuring them to make bad decisions.

Ha they literally said about 5 times in this page that people often say "it's just a skill issue"... and here you are.

I love Rust but the author's points are 100% valid.
- OP is talking about a different kind of skill issue than the article. The article is about skill issues in writing Rust code, while OP is about skill issues in choosing the right technology for the right task.
  
  Not picking Rust for code that has to be prototyped quickly and iterated a lot is kinda obvious. The solution would be to use Rust for the core engine where the requirements are clear and something else (lua? Python?) for the gameplay code. Even the engine the author wants to switch to does the same with with the divide between C++ and C#.
Well you could write code in a Ancient Greek if you want, but most people would go for English. :)

I've found that some developers enjoy picking more difficult languages because it's an intellectual challenge they enjoy, and that's fine, but some also enjoy calling others stupid because they don't enjoy the same things. That's small dick energy. :)
- Are you responding to my comment or just speaking stream of consciousness?