I'm looking forward to Rust's adoption in popular game development engines. There's https://bevyengine.org/ in the meanwhile
For people not working there, it's kind of a blackbox in term of tooling / pipeline etc ... when you work in webservices you have a ton of opensource knowledge / tools available, videogame are kind of different they re-invent a lot of the stuff in-house.
https://research.activision.com/publications/2021/09/the-rus...
Not in the actual games themselves yet that we know of, but still very cool!
My guess is that's probably a function of them thinking they can learn Rust in a weekend, because they are 10x-ers, instead of any inherent problem with the language. There is also a machismo aspect to C/C++, especially in game dev ("I eff with raw pointers all the time!").
But, if you read the article, Tim Sweeney seems to be saying "I want a fast functional language" which Rust is. One thing I am less clear on is whether Rust is better re: modularity and extensibility.
He also wants a garbage collector (pg. 57) and Pascal / ML family syntax (pg. 58). He clearly wants https://nim-lang.org/.
Since this was written in 2005, Rust/the Rust model didn't exist, so maybe Rust is memory managed/ML enough? But I am interested in looking at Nim. Had no idea it was ML influenced.
And I think I read in another comment Sweeney hired an engineer to write a new language called Verse.
FYI Nim also follows the Rust model with sink/lent annotations[0] + optimizes the (not yet default) automatic reference counting with static analysis so that RC overhead is minimized. Nim is like something between Pascal / Rust / Python, not sure why it is not more widely used.
> Sweeney hired an engineer to write a new language called Verse.
Not just an engineer, Simon Peyton Jones: https://en.wikipedia.org/wiki/Simon_Peyton_Jones
I think a lot of people want Nim, but either don't know about it, or some language feature turned them off. There are a few polarizing language design choices, but every language has something. Perhaps it just needs a killer app using it in some visible fashion (e.g., Lua in Neovim and Hammerspoon).
For context apparently Nim had a few articles written on how to write “red team” software with it and it also got popular with malware writers. Ultimately there’s an issue with AVs being lazy and flagging all Nim binaries as malware. Some of them even ignore binaries properly signed with good keys. Just another reason AVs are terrible.
I understand the necessity to detect known malware, but AVs are definitely terrible if they're unable to fingerprint the actual malicious code rather than the general traits of the toolchain used.
Also, signed binaries have proven close to useless since newly released binaries/installers raise a warning on Windows until several people run them anyway.
I think a lot of game programmers will keep an iron grip on using C/C++ for a while simply because they don't have the luxury of exploring other options. That said, I think Rust is exceedingly well designed to supplant C/C++ - game development really wants to minimize runtime failure cases and push more errors onto the compiler and static analysis due to the size and complexity of the project and Rust manages to deliver that without compromising on the performance needs - Go was a similar hopeful for a while but the lack of exception throws even under controlled situations is very difficult to deal with (I know you can panic and catch panics but it is a very rudimentary system).
I hope so!
do you think there's any possible other reason why game developers would choose to not use rust aside from some hypothetical jerkbag strawman that exists in your mind? is it possible that there's any practical reasons you haven't considered?
Ugh. That's not what I meant/said. What I meant was that there can exist a certain belief that there is only one way of doing things, when in fact there may be several. And there can be a belief that, because one has experience dealing with the most unsafe and bug ridden things, that experience is somehow necessary everywhere and all the time.
Perhaps you might try to address the question at hand, is there a certain amount of machismo re: C/C++ in game dev? Heck, everywhere?
> do you think there's any possible other reason why game developers would choose to not use rust aside from some hypothetical jerkbag strawman that exists in your mind?
Oh, totally. I'm reading the comments and looking for exactly these sorts of serious, interesting criticisms.
However, from what I've seen, some game dev criticisms have been pretty shallow from certain segments of that community. In another comment, I explain there are some game devs that have gone really deep on Rust and have really interesting things to say about it. My fear is simply that the more shallow sentiments of these high profile enfants terrible will take hold, because they often do.
Or, perhaps when you say they act big about using pointers, do you mean that they act big about using pointers safely? Because that is different. That's a conversation I began declining to have because I no longer believe it's possible for a person who is trying to use C++ for a task, and has already decided it is the best available tool for that task, to have that conversation with pretty much anybody without it devolving into a pissing match.
There is a reason "I will never be able to get the control I need (but I don't know)" or "I'll have to use unsafe everywhere (but I haven't tried)" are anti-Rust tropes. It's possible for certain game dev patterns to be awkward in Rust (really interested in hearing more about these!), but these other criticisms smell less like highly relevant informed criticism, and more like one hasn't tried Rust, as much as surface-level, mole hill criticism of hypothetical or pathological instances of bad syntax do.
It isn't that one uses raw pointers. It's much more an attitude I've witnessed in younger programmers that if they're not doing it in C/C++, they're not doing the thing. It's about vibes as much as anything else, and I think, when their heros use their own vibe-level criticisms, they only reinforce that perspective.
> Or, perhaps when you say they act big about using pointers, do you mean that they act big about using pointers safely?
No, I wasn't thinking of that, but that's another part of it. And now that you mention it, "My code doesn't have any of these issues" can be yet another defensive tact.
Do you have something you'd like to offer the discussion?
FTR, I'm not talking about jblow. I acknowledge his criticisms are superficially similar to what I wrote. At the very least jblow is seriously engaging with the arguments re: Rust, like in this thread. As to whether he's actually seriously tried to learn Rust, I'm unsure. I hope he does.
And I'm not naming names not to be passive aggressive, but for self preservation. I don't know if you noticed, but games can have a really toxic fandom.
I guess I'd also say there is another, more mature side that takes Rust much more seriously, even on Twitter, such as John Carmack. I didn't know this needed to be said but not all game devs have fragile egos, but, wow, some certainly do.
From what I've seen on HN, Zig seams to appeal people who like the “simplicity” of C and find Rust too complex, but I don't think anyone coming from C++ could find Rust “too complex” (a bit different, with a learning curve indeed, but not “too complex”).
These are frowned upon in the game industry circles. Most of the game code is C style C++ with occasional function overloading and classes.
This is obviously not as "righteous" as Rust as you put it, but when you look at the source of some shipped games, you'll see that some programming best practices are ignored.
None of this will block Zig from being used in games, of course, but I wish they had a "let me work in peace until I get this working and then we can worry about that small stuff" mode in the compiler.
And when you rely on other libraries that sort of less strict mode tends to start leaking out everywhere since that one critical library you really don't want to rewrite won't compile when you use strict and you don't want to carry a bunch of patches for it either.
The net result is if you don't start out enforcing cleanliness your community of users will unintentionally devolve into unclean over time.
Well since the package manager will be integrated to the compiler, I think they could enforce the cleanliness for people who want to publish their libraries.
yeah. players demand performance because it relates directly to a better playing experience. they demand it with their purchases and their critiques. game developers understand this inherently or they will not be a game developer for long.
honestly, i think a lot of “best practices” are nothing more than an influential person demanding compliance to their preferences, because a LOT of those “best practices” actively reduce developer productivity and runtime performance both; there’s no tradeoff, its just pure loss.
non-game developers could learn a lot from seasoned and experienced game developers, i think, but we imagine ourselves wholly superior when we absolutely aren’t.
It certainly isn't a language for every gamedev shop but some seem to be taking it seriously.
Finally. Someone gets it. It has nothing to do with the language itself. But the culture and philosophy of the tools / language / framework or library.
So while I share the general sentiment, who knows, it might actually work out. Maybe Rust can be tamed.