Wonderfully written, completely baseless.
Not meant as a criticism of Rust, but you will unseat COBOL from the finance sector LONG before you get the gaming houses onto rust.
Not impossible, highly improbable though
Why Rust Is the Future of Game Development
221–230 of 247 posts
Re: Why Rust Is the Future of Game Development
#222Earlier quoted context omitted.
Isn't this basically saying that you can't have the compiler guaranteeing you aren't including bugs in those optimizations / global variable usage because it's more efficient to just write and then ultimately ship some bugs? To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of…
That's counter productive when it comes to gamedev. Most of the code you write for a game is going to be thrown out at some point. Being able to get the idea onto the screen and iterate rapidly is worth a lot more than not having a dev build crash after a while. Make it work, make it right, make it fast except the last two are usually transposed in gamedev.
> iterate rapidly is worth a lot more than not having a dev build crash after a while
You are missing the part about wasting hours or days to investigate the crash, easily offsetting the time saved with fast and loose coding.
It would be nice to see examples to judge whether a stricter language like Rust can save more time on the debugging and fixing side (by reducing mistakes) than it costs with verbose syntax and "unnecessary" safety mechanisms on the design and coding side.
Re: Why Rust Is the Future of Game Development
#223Earlier quoted context omitted.
You tell me. How many? I am a game developer that mostly works with c++ and my answer is none so far. The projects delay but nor because of the language. Undefined behavior is c++'s strength. If it was not, we wouldnt have it in the first place
Just counting my personal experience, I've seen multiple titles fail cert and delay release thanks to bug backlogs that were mostly filled with memory issues, even after months of working to reduce the backlog of crash bugs. Perhaps you can't blame that entirely on the C++ codebase, but you sure can't absolve it entirely either. At every single studio I've worked at I've helped build out crash collecting, symbolizing…
I don't share the same experience. Crashes do happen but I wouldn't call the time sunk there a lot. If you get a ctd, usually a callstack and a bit of thought is enough for figuring out what is going on. At worst case you have valgrind. Very rarely it goes beyond that but even with that I would say it is a well trade off on how relaxed C++'s memory management is compared to Rust. And I believe C++ is relatively safe when you have well designed systems where ownership is clear enough. I have a feeling that if my company suddenly flipped to Rust now, the struggling against borrow checker would be a bigger time sink
For me majority of game development is feature development and fixing gameplay related bugs. Which will be same regardless of language you use. And depending on language feature development might be even slower
Re: Why Rust Is the Future of Game Development
#224I suggest this person writes a game in rust and then writes this article, otherwise what's the point?
Is the main issue in game development memory safety? Cos if it isn't then why would rust be better?
Whenever I see people programming in rust they are usually having to work around the borrow checker, which arguably makes them reason in a better way about their programs and also arguably wastes loads of their time doing something they know is correct but the rust compiler can't reason about.
I don't think rust has "fixed" reliability or performance issues in Firefox has it?
Re: Why Rust Is the Future of Game Development
#225Earlier quoted context omitted.
I know this is only responding to your one example, and perhaps your statement is still true generally, but I think that in this particular case it is not. In this godbolt [0] I tried using the safe version of equals with two values (from stdin so it can't just optimize the computation away, though I don't think it would) and it seems that when the compiler inlines the equals function, the inefficiencies are removed…
Right, the branch may or may not be optimized out; probably it depends on llvm's alias analysis. That's not good, it means you might break it accidentally. IME Rust is more dependent than C++ on these fragile optimizations. I think it is because idiomatic Rust is more abstract, and also because C++ has more advanced specialization features which allows implementing optimizations directly. For example in C++ you can s…
> you really do have to babysit Rust to get efficient codegen
Reminds me of the time we had to write a high performance SQL engine at university. In Java, and it boiled down to exactly the same realization: We spent a lot of time babysitting the GC instead of actually making the actual SQL engine better.
The plan was to use C++ instead, but that option was dropped by the lecturer shortly before the project started :/
Re: Why Rust Is the Future of Game Development
#226Earlier quoted context omitted.
if your game is riddled with bugs... you make no money or at least less. further, the whole point of rust is that is fast and safe. safe doesn't imply slow. a lot of game development is entity component systems, and there are several of those for rust - it will be a matter of time until these are good and fast enough to be used in larger and larger games.
Fallout 4 and the latest Modern Warfare beg to differ (with the first point).
The new AC:Valhalla as well. Pretty much any new sport EA game too. Wasteland 3 has been riddled with game breaking bugs on launch and still people have been buying it like there is no tomorrow.
Re: Why Rust Is the Future of Game Development
#227Earlier quoted context omitted.
I think it's more likely than not, yes. Jonathan Blow has a reputation for taking a rather long time to release something eagerly awaited, and the result being impressive and critically acclaimed. I hope Jai will be the same way. We'll see what happens.
Sure, but that works for a game where you can release it once and then everyone consumes it. Languages are ecosystems. They have tools, and libraries, and shims to integrate with other tools. They need evangelism. They grow with community involvement. As far as I know, no one has ever released a new language that was perfect in its initial release - there has always been feedback and syntax quirks that get addressed…
Jai is foremost for Jonathan Blow's own usage in his games, whatever happens with it beyond that I doubt he couldn't care less.
There are private betas available by the way.
Re: Why Rust Is the Future of Game Development
#228Sorry, but the learning curve of a programming language matters a lot. It's already hard enough for people to read and write code, so to learn another hard language like rust is not something you do lightly. Rust is a cool language, but it's a cool tool, nothing more. I'd rather see the ownership process implemented in some C/C++ dialect. I'm not entirely sure, but I think that C++ concepts, in a way, have the same g…
> I'd rather see the ownership process implemented in some C/C++ dialect.
Here you go,
https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl...
https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...
Re: Why Rust Is the Future of Game Development
#229Earlier quoted context omitted.
Just counting my personal experience, I've seen multiple titles fail cert and delay release thanks to bug backlogs that were mostly filled with memory issues, even after months of working to reduce the backlog of crash bugs. Perhaps you can't blame that entirely on the C++ codebase, but you sure can't absolve it entirely either. At every single studio I've worked at I've helped build out crash collecting, symbolizing…
I don't share the same experience. Crashes do happen but I wouldn't call the time sunk there a lot. If you get a ctd, usually a callstack and a bit of thought is enough for figuring out what is going on. At worst case you have valgrind. Very rarely it goes beyond that but even with that I would say it is a well trade off on how relaxed C++'s memory management is compared to Rust. And I believe C++ is relatively safe…
> I don't share the same experience.
You can say that again!
> If you get a ctd, usually a callstack and a bit of thought is enough for figuring out what is going on.
Very different experiences. Sometimes that happens.
Sometimes the symbols have been evicted from the symbol server. Sometimes the minidump didn't capture relevant memory (and the full dump would be a couple dozen gigs, making external QA reluctant to constantly capture those). Sometimes the crash is the result of memory corruption from unrelated systems minutes ago that doesn't reproduce when you enable any of your debug allocators because reproing relies on pointer reuse in a hashtable. Frequently custom allocators defeat tools like valgrind and address sanitizer, requiring extra work to either bypass or explicitly annotate valid/invalid memory ranges. Sometimes the process only exit(3)s (technically not even a crash!) from an unrelated thread on a specific bit of UI with no relevant callstacks nor logging, and if you open up the windows charm bar for more than 10 seconds without a debugger attached, and you resort to bisecting p4 history once you've spent the several days even figuring out repo steps.
That wasn't even our bug, but it was our workaround... even when the codebase is good, the middleware often isn't! And that is but one of many I've had to deal with.
> C++ is relatively safe when you have well designed systems where ownership is clear enough.
Meanwhile, the poster I was originally replying was pointing out that you can have unclear object ownership full of globals and C++ is somehow supposedly good at dealing with this. Hopefully you're at least agreeing with me here, in disagreeing with that! :)
A lot of gamedev code isn't very well designed, IME, and "relatively" safe can be suprisingly unsafe as well.
> I have a feeling that if my company suddenly flipped to Rust now, the struggling against borrow checker would be a bigger time sink
The first couple months after I picked up Rust, I had that phase. Now it's quite easy for me - sometimes it requires a deep `.clone()` or two, but in the equivalent C++ codebase you wouldn't have even dreamed of not making the deep copy - because in equivalent C++ code it'd be impossible to do the equivalent fancy zero-copy borrowing nonsense even remotely safely.
Re: Why Rust Is the Future of Game Development
#230Earlier quoted context omitted.
At this point, does anyone seriously expect JAI to ever be released? It's been 6 years.
I think it's more likely than not, yes. Jonathan Blow has a reputation for taking a rather long time to release something eagerly awaited, and the result being impressive and critically acclaimed. I hope Jai will be the same way. We'll see what happens.
Yes and I have a strong suspicion that the upcoming Braid "Anniversary edition" is actually a rewrite using the new language.