Maybe the right question to ask is, why you have 4.8 billion empty tuples? And why you're still on a 32-bit system?
There is a lot of 32 bit microcontrollers, most notable stm32
Admittedly, those probably aren't running on 32-bit systems, nowadays ...
But you are going to need some minimal buy-in from Microsoft first, if not Sony and Nintendo too.
The great thing about carbon is that you can incrementally shift a codebase over from c++, and there are no problems interacting with existing c++ APIs, so the required amount of buy-in is pretty much just "yes, you can use a 3rd party compiler" and maybe some improvements to the debugger.
You actually have to wrap all the c++ functions in c functions, and then call those c functions from rust. Which requires either making manual wrappers, or automated wrapping tools that handle the specific idiosyncrasies of the library you are calling.
Which is a massive barrier; Gamedev standardised on c++ and there are so many c++ libraries.
In comparison, Carbon is designed from the ground up to automatically have bi-directional inter-op with c++. It's what the language is designed to do.
Things must be initialized in Rust. Things must have a single identifiable owner. Things really want to be immutable.
Sure, you can duck these in Rust with lots of "unsafe". But, if you do that, are you really gaining anything from using Rust?
However, the purpose of unsafe is to mark code that does something which a human needs to check for correctness. We're not saying "This isn't OK" but "The compiler can't check this is OK, so a person needs to do so". If you write C++ today, all of your code is like that. I'd be astonished if more than a tiny proportion of the actual game code in a modern video game needed that treatment in Rust.
For example, Rust's approach to late initialization is std::mem::MaybeUninit<T>, a wrapper type which says to the compiler hey, I am not initialized yet, it's OK to write a T value into me, but you can't read my value until somebody says they're done initializing me. The "say you're done initializing" part is indeed unsafe, but that's a small part of the program. That intern writing a zone preview gadget? They don't need to be writing unsafe initialization code, when they try to access preview_zone.orb_color the compiler tells them this is MaybeUninit and so they can't read it. "Huh, apparently orb_color is MaybeUninit ?" "Oh, just show all the orbs in preview as orange, it'll be fine". You just avoided Undefined Behaviour and possibly a trip to the land of "But it works in debug builds".
> But, if you do that, are you really gaining anything from using Rust?
In each new release of Bevy, they've found soundness bugs with the borrow checker—seems like they're gaining something.
Triangle meshes can be stored quite efficiently and a lot of the modern geometry is tessellated, procedural or replicated.
There are far better optimizations for gamedev like using SOA instead of AOS.