[joz1-k]

> If it was written in C++, there's a good chance it was so for performance reasons.

I agree. But imagine that games like Doom or Quake would have been unthinkable if they weren't fully written in C/C++. Now, however, we have 3D game engines like Unity that expose a C# API for game logic scripting, and it seems to work just fine. Performance is becoming less of a concern for more and more problem domains.

[pjmlp]

With lots of Assembly, inline Assembly isn't C or C++, regardless of how many devs might pretend otherwise.

It is like saying C libraries are Python, only because they happen to be used from Python bindings.

[tialaramex]

If you want assembler Rust seems like a smarter choice because in Rust that's just part of the language whereas in C or C++ it's a vendor extension.

[pjmlp]

Assembly is never really part of the language, at most one could consider the syntax to inject a stream of opcodes being part of the language.

Both of us are old enough to remember when any useful compiled language used to allow for inline Assembly, extension or not.

[thrance]

True, but I would guess that projects more susceptible to rewrites would be low-level core libraries where state-of-the-art performance is always desirable.

[joz1-k]

Correct. And if those projects exposed a C++ API, then rewriting them in Rust would be highly problematic, because Rust did not prioritize C++/Rust interoperability (for well-understood reasons). So, you can either have a C API and move to Rust or have a C++ API and create a Rust version of the library for Rust developers, but your original users of the C++ library will stick with the C++ version.