107
Leaving Rust gamedev after 3 years
(loglog.games)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Apr 2024
107 points (96.5% liked)
Rust
6025 readers
1 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
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
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.
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?
Pretty much. If you're using Godot 4, you use gdext, and for Godot 3, use gdnative.
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:
defer(), which is nice, but I much prefer Rust'sMutex<T>to Go'sdefer m.Unlock()Result- even worse,(*int)(nil) == nilbutinterface{}((*int)(nil)) != nil- so checking fornilisn't even always what you expectEach 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.
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]Vshould be concurrency-safe, or at least have a safe counterpart w/o needing an importinterface{}(T(nil)) == nil- or better yet, no nil at allThose 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...
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).
Honestly, I disagree, but I obviously haven't seen the code in question.
Go has a lot of really nice things going for it:
My problem isn't with normal program flow, but that the syntax is deceptively simple. That complexity lives somewhere, and it's usually in the quirks of the runtime. So it's like any other abstraction, if you use it "correctly" (i.e. the way the maintainers intended), you'll probably be fine, but if you deviate, be ready for surprises. And any sufficiently large project will deviate and run into those surprises.
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.