[phire]

Carbon is probably Gamedev's best chance of moving beyond c++

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.

[cesaref]

What about rust?

[phire]

It's complicated to call a c++ library from rust.

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.

[bsder]

As much as I love Rust, it really has a significant impedance mismatch at the low-level with GameDev.

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?

[tialaramex]

I agree with you that Rust isn't a perfect match for video game development. Jonathan Blow's Jai is targeting that sort of program, it's not offering Rust's safety promises (Jon is confident this doesn't matter) but it can hardly be less safe than C++.

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".

[erichocean]

And yet…Bevy exists and has a nice API.

> 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.