The rise of Unity (C#) and Godot (GDScript or C#) would make me think that most game code is starting to move away from raw C++ — but of course the core engine code is still C++ indeed.

"would make me think that most game code is starting to move away from raw C++"

Godot is talked about on Hacker News but it's nowhere in the industry, as for C++ it's the default language for games and it will be the case for the foreseeable future.

I feel that there is a real disconnect between hacker news and people working in the industry.

Most people here don't seem to understand how different it is from your regular CRUD app compagny.

While the disconnect is true, specially in what concerns FOSS views of the world and how real studios work, middleware like Unity and WaveEngine are indeed being picked up by major studios.

On the Switch alone, a very big chunk are all based on Unity, more than 50% as per Unity official statement.

Also although the engine is still mostly C++, they have been porting the rendering pipeline into HPC#.

Engine development and game development are two different things. For gameplay/scripting, even in 90s there were alternative languages. The way Unreal uses C++ (i.e. as scripting) is not different to how Unity uses C#.

At some point, every game development project becomes engine development :-)

Yep, it even has a GC for the C++ based entities.

Unity has a c# scripting api, layered on the core c++ foundation. Unreal, on the hand, is C++ top and bottom.

> Unreal, on the hand, is C++ top and bottom.

They have Blueprints[1] (visual scripting) and had a scripting language. However, they have removed it since then.

1: https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...

A runtime scripting language is coming back in some form or another thanks to Epic acquiring the SkookumScript team.

cxx [1] is a relatively recent effort to enable safe interop with C++.

Mozilla has also published information on how they are rewriting components in Rust and integrating them into the Firefox codebase, though they were using C apis - exposing Rust to C and vice versa is relatively straight-forward.

[1] https://github.com/dtolnay/cxx

Godot is written in C++, but it has a stable C ABI, so it's pretty straightforward to include functionality written in Rust.

They have [semi?]official bindings for Rust https://github.com/godot-rust/godot-rust

I don't think there's anything official about it? Anyone can create bindings from their language of choice to GDNative.

Unless the maintainer is directly involved in godot or something (I couldn't see any evidence of this from quickly checking their profile), it looks like a community effort to me.

Rust has good C interoperability. So from C++ it’d look like a C library. You can either write your own glue code or use something like cbindgen to autogen the header file.

Many interesting SDKs come with C++ APIs that aren't necessarily translatable to C. Choosing Rust for engine development has the potential of severely hamstringing the team. It is the same tough uphill battle for all languages that aren't C++. Even more so now that the smoke is slowly rising from the battlefield of licensed engines and only a few contenders remain standing. And all of them have a massive C++ codebase and litttle incentive to toss that out.

If there will be a transition to any other language in that space, it'll take a decade or two.

There is an effort to automate generating mid-level C bindings for C++ code automagically, to enable easier wrapping in high level Rust APIs, by an unofficial Academy [of Motion Pictures] Software Foundation group. It is called C++-- [1].

At this time we only target the VFX C++ ecosystem but I'd be surprised if people wouldn't use (and extend) this to cover a broader set of C++ libs.

Maybe you can give an example of a C++ API that you deem not "translatable to C"?

[1] https://github.com/vfx-rs/cppmm

For example, OpenVDB uses templates with user provided arguments at the very heart of its tree structure. Similar things happen in PCL and CGAL. They are template-heavy libraries by design.

OpenCV on the other hand seems to instantiate all possible variants of cv::Mat for their Python bindings. They don't such a big space of valid and useful template parameters and IIRC the specifics are abstracted away from the algorithms working on them.

That's kind of hilarious given the role that C++ to C compiler had in the early development of the language [1]. But sounds useful, thanks for the link.

[1] https://en.wikipedia.org/wiki/Cfront

There is also this, [1], which wasn't on my radar until today:

"Corrosion, formerly known as cmake-cargo, is a tool for integrating Rust into an existing CMake project. Corrosion is capable of importing executables, static libraries, and dynamic libraries from a crate."

[1] https://github.com/AndrewGaspar/corrosion

True, Google is at least trying to make it easier to bind to C++ [0]. It's still pretty experimental, though.

0: https://github.com/google/autocxx

Interestingly, somebody pointed out in a previous discussion that a potentially significant interoperability hurdle (which is the case for the Qt libraries) is that, if a library makes use of multiple inheritance levels, it translates poorly into any language not supporting inheritance.

The vast majority of games are indeed developed in other languages than C++. The native languages of the most widely used game platforms are C# for anything done with Unity, Java/Kotlin for Android, and Swift/Objective-C for iOS.

The C ABI is the lingua franca still, you can call it from all of the above. And you can expose a C ABI for your Rust library.

There's something called a foreign function interface that allows rust to access compiled c++ or c primitives.

simple matter of programming