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
At every single studio I've worked at I've helped build out crash collecting, symbolizing, or deduplicating infrastructure just to get a lead on where shit is exploding, and seen major productivity outages when tooling crashed frequently enough to disrupt the workflows of my coworkers. Address sanitizer, valgrind, extra debug allocators - I've sunk a lot of time into just making these crashes shallower to debug and quicker to catch.
One of the smallest and quickest projects that comes to mind was an NDS -> iOS and Android port. Do you think most of the time was spent in porting APIs and control schemes? More than half the time on that project was spent just chasing down really stupid memory related crash bugs that were exacerbated in frequency and time by the port. I made damn sure to communicate my concerns about the schedule, and if my memory serves me correctly, we managed to soft launch "only" a week or two late.
C++'s strengths are it's lean portability, speed, and huge existing codebases and tallent pools. Undefined behavior is simply the cost we begrudgingly pay, not it's strength, and even that we often mitigate by trying to figure out ways to write as little C++ as possible - keeping it only for the parts of our codebase that are actually performance sensitive. Tooling is often C#, Python, anything but C++. UB is a pox and constant time sink.
Whenever people call out C++'s UB as it's strength, I'm left wondering how many of their bugs do they actually fix, and how many are begrudgingly fixed by their coworkers. Most of the people whom I've worked with with that attitude don't pull their own weight in the debugging department, so they don't see the full costs of it.
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
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.
Bullshit.
How many games have had releases delayed and major wrenches thrown into marketing plans because of progress ruining heisenbugs? How many failed certification passes from banal data races and other undefined behavior?
We trap UI in actionscript or javascript, and gameplay programmers in other scripting languages - perhaps python or lua - for faster iteration times, hot reloading, and safety. Because it's difficult enough to keep the build stable when it's merely all the engine programmers who should know better screwing things up with C++.
This results in large messes of poorly performing, poorly optimized, garbage-collector laden code that Rust would handle much faster. We're leaving lots of performance on the table, often for little other purpouse than "safety".
Console first day patches may have taken off some of the pressure for getting the first release right, but handhelds aren't always online and still have a pretty high bar.
> the optimizations required are typically unorthodox
Rust's `unsafe` keyword and intrinsics let you do all the unaligned intrinsic-laden data-racey technically-undefined-behavior micro-optimizations you might want to do in C++ in Rust just fine.
It'll hopefully trigger a more stringent code review and force you to justify your pile of bugs, but that's a good thing. Or you can skip the code review if your entire company really disagrees.
> a super strict language slows development down
C++ is also super strict, just in an unenforced-at-compile-time way that result in plenty of late nights chasing heisenbugs. Don't get me wrong - language strictness can slow development down - but that's one of the reasons people eschew C++, too.
As for C++ vs Rust? I'm going to spend more time and be far less certain of catching the issues in a C++ code review than I would be in a Rust code review. And while it took a few months for my development speed in Rust to catch up with my development speed in C++, it did happen.
Rust merely forces you to acknowledge when you're being sloppy.
> Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state.
I have solved so many sources of endless heisenbugs by eliminating some of these global variables. John Carmack as far back as 2013 was using phrases like "horror show" to describe similar parts of his own codebases[1] and has been agitating for more functional styles.
An unclear mudball of global variables is entirely possible - and easy - in Rust if you really want that. You merely need to make it either thread safe, or resort to `unsafe` if you really can't tolerate the overhead of not having threading-related heisenbugs.
[1]: https://youtu.be/1PhArSujR_A?t=125