Hacker News new | ask | show | jobs
by thrance 266 days ago
> Fully automatic memory-managed languages should be considered first.

Why? If it was written in C++, there's a good chance it was so for performance reasons. You wouldn't want to throw that away with a GC.

1 comments

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

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.

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

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