As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Usin…
When will an editor be added? That’s what’s holding me back from jumping into Bevy. I actually think Rust is really hard, but I also think it would be beneficial to my career.
Leaving Rust gamedev after 3 years
411–420 of 996 posts
Re: Leaving Rust gamedev after 3 years
#412Earlier quoted context omitted.
Also C++ could be adopted incrementally by C developers. You could use it as “C with classes”, or just use operator overloading to make vector math more tolerable, or whatever subset that you happened to like. So there’s really three forces at play in making C++ the standard: 1) The Microsoft ecosystem. They literally stopped supporting C by not adopting the C99 standard in their compiler. If you wanted any modern co…
I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs
There's no other internal or external Microsoft /support/ that I'm aware of. I wouldn't necessarily use it as a signal of the company's intentions at this time.
That said, there are Microsoft folks working on the Rust compiler, toolchain, etc. side of things too. Maybe those are better indicators!
Re: Leaving Rust gamedev after 3 years
#413That's a good article. He's right about many things. I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust. Notes: * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be writ…
> The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?
A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale."
Putting aside that not all of use are building web applications (heterodox here in HN, I know)...
Most people in the real world with real applications will not hit the limits of what is possible and efficient and totally fine with thread-based architectures.
Plus the kernel has gotten more efficient with threads over the years.
Plus hardware has gotten way better, and better at handling concurrent access.
Plus async involves other trade-offs -- running a state machine behind the scenes that's doing the kinds of context switching the kernel & hardware already potentially does for threads, but in user space. If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.
That overhead is fine if you're sitting there blocking on your database server, or some HTTP socket, or some filesystem.
It's ... probably... not what you want if you're building a game or an operating system or an embedded device of some kind.
An additional problem with async in Rust right now is that it involves bringing in an async runtime, and giving it control over execution of async functions... but various things like thread spawning, channels, async locks, etc. are not standardized, and are specific per runtime. Which in the real world is always tokio.
So some piece of code you bring in in a crate, uses async, now you're having to fire up a tokio runtime. Even though you were potentially not building something that has anything to do with the kinds of things that tokio is targeted for ("scalable" network services.)
So even if you find an async runtime that's optimized in some other domain, etc (like glommio or smol or whatever) -- you're unlikely to even be able to use it with whatever famous upstream crate you want, which will have explicit dependencies into tokio.
Re: Leaving Rust gamedev after 3 years
#414Earlier quoted context omitted.
> I'd expected some AAA title to be written in Rust by now. I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until…
Exactly, it's all about the ecosystem and very little about the language features
Re: Leaving Rust gamedev after 3 years
#415Earlier quoted context omitted.
Yeah this is a common problem in the industry, we rarely have enough time to refactor what should be considered prototype-level code into robust code.
The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more. Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a…
Re: Leaving Rust gamedev after 3 years
#416Earlier quoted context omitted.
Also C++ could be adopted incrementally by C developers. You could use it as “C with classes”, or just use operator overloading to make vector math more tolerable, or whatever subset that you happened to like. So there’s really three forces at play in making C++ the standard: 1) The Microsoft ecosystem. They literally stopped supporting C by not adopting the C99 standard in their compiler. If you wanted any modern co…
I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs
Re: Leaving Rust gamedev after 3 years
#417Earlier quoted context omitted.
I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs
Repo contributor here, just to curb some expectations a bit: it's one very smart guy (Kenny), his unpaid volunteer sidekick (me), and a few unpaid external contributors. (I'm trying to draw a line between those with and without commit access, hence all the edits.) There's no other internal or external Microsoft /support/ that I'm aware of. I wouldn't necessarily use it as a signal of the company's intentions at this…
Thanks for your work, though!
Re: Leaving Rust gamedev after 3 years
#418Earlier quoted context omitted.
> I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either. Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone someth…
And yet it is incredibly productive. The poster that contrasted engineers with artists got it right I think. Go is an engineer’s language.
No, Ada/Spark is an example of a good engineers language. Go is a mediocre effort at best. Rob Pikes defence is that it was designed for junior Googlers who "aren't capable of understanding a brilliant language". Yes that's a real quote.
Re: Leaving Rust gamedev after 3 years
#419Earlier quoted context omitted.
I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript). So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore w…
Perhaps the more appropriate advice is : Use the right tool for the job. Use C++ for writing a high performance library or a database engine. Use Go or Java for writing a server. Use C for writing a kernel module. Use shell scripts for automation. Use python for trying out ML ideas or heavier duty scripts. Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right…
Re: Leaving Rust gamedev after 3 years
#420Earlier quoted context omitted.
Exactly, it's all about the ecosystem and very little about the language features
C++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.