Leaving Rust gamedev after 3 years : rust

[–] [email protected] 31 points 5 months ago* (last edited 5 months ago) (3 children)

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.

[–] [email protected] 31 points 5 months ago (3 children)

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.

[–] [email protected] 15 points 5 months ago

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.

[–] [email protected] 8 points 5 months ago

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.

[–] [email protected] 5 points 5 months ago

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.

[–] [email protected] 14 points 5 months ago (1 children)

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

[–] [email protected] 11 points 5 months ago* (last edited 5 months ago) (1 children)

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.

[–] [email protected] 5 points 5 months ago

I agree with you about the tradeoffs that C# and Java make to gain ease of use at the cost of memory use. In a lot of cases that's a fine tradeoff. It doesn't matter much too me whether an indy game needs a little more memory. I'll also agree that C is going to be less safe than Rust (and Java, C#). But I still think it's an easy language to iterate in. It's a very simple language.

[–] sugar_in_your_tea 4 points 5 months ago

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.

[–] [email protected] 27 points 5 months ago (2 children)

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

[–] [email protected] 13 points 5 months ago (17 children)

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.

[–] [email protected] 5 points 5 months ago (3 children)

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

[–] [email protected] 7 points 5 months ago

The borrow checker is useful for a lot more than memory safety. This is something I have been repeating for years, but unfortunately people new to the language don't understand it yet.

E.g. Rust is the only mainstream language where it isn't possible to read from a file handle after it's been closed. There are numerous other common benefits of it that apply to general purpose programming, like not being able to mutate a collection while you're iterating over it.

It's a very common practice in Rust to enforce domain invariants using Rust's ownership rules, and those things cannot be enforced at compile time in other languages that don't have ownership.

The borrow checker is also usually pretty easy to get around with just a bit of experience in Rust.

[–] [email protected] 5 points 5 months ago

It's not like Rust is the first language which requires you to reason about ownership. People still write tons and tons of C++. Rust is much faster to write than C++ in my experience, because ownership is checked by the compiler instead of requiring the human programmer to constantly think and reason about.

I wouldn't write gameplay code in Rust like I posted above, but most of the complaints about the borrow checker making Rust somehow exceptionally hard to write are overblown imo. There's a learning curve but then it makes sense.

[–] [email protected] 3 points 5 months ago

Antagonizing the borrow checker is wrong. If it screams it does so to prevent you from writing a mistake. Eventually once you have enough experience you should write code in such a way that doesn't trip the borrow checker because you know how to properly handle your references.

Is it difficult to learn at first? Yes, but the benefits of learning this outweighs the downsides such as writing code that may use references when it shouldn't.

I'm not a Rust aficionado, but the few Rust I've written opened my eyes on issues that I have been dealing with in other languages but for which I was blind.

Lastly I tried following a Godot project tutorial that was using GDScript except I challenged myself to follow it but rewrite the examples given using Rust's bindings for Godot. It was definitely more cumbersome to work with, but I might also have been doing something wrong (such as blindly transcribing GDscript instead of writing more idiomatic Rust).

All of that to say 1) borrow checker is your friend and 2) scripting languages will always be more convenient at the cost of being way more dirty (way less safeties)

In the end you need to pick the right tool for the job. Multiple tools may be used within the same project.

load more comments (16 replies)

load more comments (1 replies)

[–] [email protected] 23 points 5 months ago* (last edited 5 months ago) (6 children)

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

[–] [email protected] 25 points 5 months ago (1 children)

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.

[–] [email protected] 13 points 5 months ago (1 children)

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

[–] sugar_in_your_tea 4 points 5 months ago (1 children)

Exactly. I make games for a hobby in Godot, and my workflow is to iterate in GDScript and optimize in something faster (I wrote a world gen in Rust).

Most of a game's performance is going to be in the engine in shaders, physics, etc, so most of your logic could very well be in a scripting language.

[–] [email protected] 2 points 5 months ago (1 children)

How well does Godot integrate with modules written in other languages? I assume you have to compile a library for each target platform on your Rust component and then link it dynamically in Godot somehow?

load more comments (1 replies)

[–] sugar_in_your_tea 14 points 5 months ago (2 children)

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.

[–] [email protected] 3 points 5 months ago

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.

[–] [email protected] 2 points 5 months ago (1 children)

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.

[–] sugar_in_your_tea 3 points 5 months ago* (last edited 5 months ago) (1 children)

Oh yeah, that is really nice, and something fantastic about Go.

That said, I found that I care about that a lot less now than I used to. With everything running through CI, having a build take a few minutes instead of a few seconds isn't really a big deal anymore. And for personal things where I used to build small Go binaries, I just use Python, mostly because it's easier to drop into a REPL than to iterate with Go.

I like Go in theory, and I hope they fix a lot of the issues I have with it. But given that Go 2 isn't happening, maybe it won't. Or maybe they'll do the Rust editions thing (seems to be the case in that article) so they can fix fundamental issues. IDK. But I'm guessing some of the things I want aren't happening, like:

map[K]V should be concurrency-safe, or at least have a safe counterpart w/o needing an import
destructors, or something like Rust's Drop trait
interface{}(T(nil)) == nil - or better yet, no nil at all
slices shouldn't be able to write beyond their bounds (example here)

Those are pretty fundamental to how Go works, though maybe the last one could be fixed, but it has been there since 1.0 and people have complained since 1.0...

[–] taladar 2 points 5 months ago (1 children)

I haven't really written any Go but from trying to debug some issues in Go software and looking at the source code it seems to be the kind of garbage language that is write-only and likely most major projects written in it will take a full rewrite if you want to overhaul it for a new major version (as in the kind of major version where the code base changes significantly, not the kind where you just broke some minor API).

load more comments (1 replies)

[–] [email protected] 9 points 5 months ago* (last edited 5 months ago) (1 children)

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.

[–] [email protected] 10 points 5 months ago

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

[–] [email protected] 5 points 5 months ago

What makes Python tragic?

[–] [email protected] 2 points 5 months ago

Python is tragic? Why?

load more comments (1 replies)

[–] [email protected] 15 points 5 months ago (1 children)

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

[–] [email protected] 12 points 5 months ago* (last edited 5 months ago) (6 children)

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.

[–] [email protected] 5 points 5 months ago (1 children)

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.

[–] [email protected] 2 points 5 months ago (1 children)

You can, of course. And if you're good enough at it, and focus on keeping it simple, you can keep the complexity down to a minimum, at least with most straightforward programs.

Buut you can say the same about other complicated languages like c++. And things like writing quick "shell script" type things are going to be pretty simple in almost every decent language. Even if the result is slightly more verbose it won't really matter.

[–] [email protected] 4 points 5 months ago (1 children)

For me the biggest difference between Rust and C++, for things like scripting, is cargo. Being able to just add an awesome parser, or support for a particular file-format, to my "script" with a single line in cargo.toml is awesome. In this particular way cargo is better than Python even. The amount of time spent on acquiring, setting up, and linking libraries in other languages cannot be understated.

[–] [email protected] 3 points 5 months ago

yeah rust along other new languages takes package management (and some other "hard learned lessons") seriously, which gives it an advantage over most older languages (and it's ahead other newer languages in that there is a serious amount of adoption for rust.. a package manager that has no packages to manage is not very useful)

load more comments (5 replies)

[–] [email protected] 10 points 5 months ago (1 children)

The hacker news comments are as usual very good too

lol

[–] [email protected] 2 points 5 months ago

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

[–] [email protected] 5 points 5 months ago

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.

[–] sugar_in_your_tea 2 points 5 months ago* (last edited 5 months ago)

First of all, I think Rust is a poor choice for games for a few reasons:

you're better off using a bigger game engine - Rust game engines are hobby projects, whereas Godot and Unreal Engine are production projects
games often have complex data structures that don't play nice with the borrow checker - you can make it work, but to get great performance, you'll need to irritate a lot on non-game logic; save those tricks for servers, kernels, etc
performance critical paths tend to be in the engine, not game logic

In general, my advice is:

use scripting languages with a popular engine by default, optimize in something compiled (so Rust as a library language)
don't optimize performance until the logic is stable
handle threading from the start

And specific reactions to the article:

Throw away code in Rust

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 and games specific stuff

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...

Rust community

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.

Macros and reflection

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 and dev loop

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

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.

Conclusion/TL;DR:

I looked into alternatives, found gdnative, and then was recommended godot-rust. It wasn't the first time I've seen or used Rust, but it was the first serious usage for game development, being preceeded only by game-jam-y projects.

Since then Rust was the langauge I used for everything.

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

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.

Rust

Wormhole