This was a really good summary of what Rust feels like in my opinion. I’m still a beginner myself but I recognize what this article is saying very much.
The hacker news comments are as usual very good too:
This was a really good summary of what Rust feels like in my opinion. I’m still a beginner myself but I recognize what this article is saying very much.
The hacker news comments are as usual very good too:
First of all, I think Rust is a poor choice for games for a few reasons:
In general, my advice is:
And specific reactions to the article:
Throw away code in Rust
The Rust equivalent is to wrap everything in a Box and use
unwrap()
everywhere. For multithreaded logic, wrap it inArc
as well. That tends to eliminate most borrow checker problems.So I do that when working on a new part of the app, and then fix things later. I just did a round of that this past weekend on a project where I switched everything to
&str
, removedunwrap()
, etc.So you can absolutely do the “tech debt now, fix later” approach in Rust.
ECS and games specific stuff
Agreed, but it’s matters far more in the engine than in game logic. Just do the inefficient thing now and save the refactor for later.
The OP says they want to use something else to kick the performance can down the road, but for some reason isn’t willing to do the same in Rust. Not sure why that is…
I haven’t used an ECS much, so I’ll stop here.
So why go with experimental libraries in Rust like Bevy? AFAIK, the number of people shipping real games in Bevy is probably in the single digits.
Use a big engine like Godot or Unreal if you want to ship a real game. Use something like Bevy if you want to scratch the brain itch.
Right, which is why most studios write game logic in a scripting language first and move heavy logic to something faster.
I started a game project with a friend. They wanted C++ and I wanted Rust, so we wrote in Lua and wrote competing servers. The vast majority of the logic was (and still is) in Lua, with only a small amount in C++ (we abandoned my Rust code because the other dev didn’t understand it).
Use the right tool for the job…
Rust community
Sure, and this is a good thing. But don’t mistake positive reinforcement for that being the right way to do something in your case.
I evangelize Rust quite a bit, but I also use Python and Lua for things that need fast iteration.
Agreed, which is why I bailed after a week or so messing with stuff. It was obvious at the time that everything was half-baked and I’d be fighting the engine more than my game logic.
Rust game dev projects are a cool hobby, I wouldn’t rely on any for a production game though.
Agreed.
Macros and reflection
They never were. I don’t know who claimed they were, because that’s a fundamental misunderstanding of what reflection is.
There are two types of reflection:
Rust macros are like halfway to compile-time reflection, but it’s still a long way off. It’s great for automating trait impls and other forms of code generation, but it’s not enough to actually do reflection.
Also, compile time reflection, while powerful, is not nearly as nice to use as runtime reflection, and Rust will likely never have that. So design your problems so reflection isn’t needed, and don’t lie and tell others Rust has it.
Hot reloading and dev loop
Agreed. Use a scripting language for rapid iteration.
I think this is the main problem here. OP seems like to use Rust, you need to obsess over performance and “do things correctly.” You don’t. Full stop.
The main benefits of Rust to me are:
Use it where you get the most value from those benefits, use a scripting language where you don’t.
Again, use a scripting language. In same dev, you shouldn’t be recompiling so often that this matters.
Also, I wonder if Cranelift helps here.
Positives of Rust
Yup, that’s why I use it.
That’s nice, but secondary to the first. In fact, I’d put this quite a bit further down my list, since performance is rarely my bottleneck.
Honestly, these are almost enough reason to switch to Rust on their own.
Absolutely, they’re another killer feature that I wish more languages had. I love being able to write relatively abstract code like:
fn do_stuff<A, B>(arg_1: A, arg_2: B) where ( A: Hash, Ord, ..., B: ... )
And be able to use pretty much anything I want. That’s also a great thing about Go, I can just make an interface and use anything that implements it.
In C# and Java, I need complex inheritance chains and to be extra careful about not writing too much in the base class that I’ll need to bypass stuff later. In Rust, I can just throw anything that fits the requirements, and even reuse random stuff from crates.io and add a couple trait impls without having to wrap it in an internal type.
They’re really nice.
Conclusion/TL;DR:
Sounds like they overcorrected their problem (Godot pathfinding is slow) to “Rust all the things,” and now they’re overcorrecting the other way to “C# all the things.”
It’s okay to use multiple tools to solve a problem, use the right one for the job, and have a tool belt of well maintained tools.
What I use
Anyway, that’s my take. Thanks for the writeup, I hope the helps people.