In other languages one can write code with “I can throw this away later” in mind

The Rust equivalent is to wrap everything in a Box and use unwrap() everywhere. For multithreaded logic, wrap it in Arc 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, removed unwrap(), etc.

So you can absolutely do the “tech debt now, fix later” approach in Rust.

ECS… in games performance matters

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.

I’m not evaluating Rust from the perspective of technical curiosities or “this scratches the right brain itch”. I want to make real games that will get shipped to real people (not developers) in reasonable amount of time

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.

Making a fun & interesting games is about rapid prototyping and iteration, Rust’s values are everything but that

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…

Because of the general vibes in the Rust community it’s very common for people to receive very positive reinforcement on what they’re building

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.

Rust gamedev ecosystem lives on hype

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.

GUI situation in Rust is terrible

Agreed.

Procedural macros are not even “we have reflection at home”

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:

• runtime reflection - basically what Go, Java, and C# have; I’ve mostly used Go’s, which is pretty nice, but there are plenty of footguns there
• compile time reflection - the only one I’m familiar with is D’s compile time reflection library

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 is more important

Agreed. Use a scripting language for rapid iteration.

But it’s especially sad for a language that aims to be so fast and optimal to have to resolve to wasting cycles on re-allocating memory more often than one would like, just to stay productive.

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:

• compiler checked concurrent memory access - it stops you from writing wrong memory access
• no traditional OOP, so you have to try harder to get into inheritance hell, but you have the tools to get most of the benefits
• nice ergonomics - cargo, macros, etc make writing code pleasant

Use it where you get the most value from those benefits, use a scripting language where you don’t.

Compile times have improved, but not with proc macros

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

If it compiles it often kinda just works

Yup, that’s why I use it.

Performance by default

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.

Enums are really nicely implemented

Honestly, these are almost enough reason to switch to Rust on their own.

Traits

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.

• JavaScript for UX for non-game projects - I use Tauri for my project
• Godot for games - GDScript by default, Rust for the CPU intensive bits like pathfinding, world gen, etc
• Python for scripts
• Lua for non-Godot games and other apps - will probably add to my app soon once I get to stuff that needs rapid iteration
• Rust for servers that need to be fast, Python for servers that don’t

Anyway, that’s my take. Thanks for the writeup, I hope the helps people.