> and everything else (games, system programming, embedded programming with an OS, etc) has mature and better options available such as Rust, Go, Nim, and (particularly for gamedev) C#.
None of the options you mention, other than possibly Rust,is actually appropriate for game engines, systems programming, or embedded, due to the garbage collector. There are still plenty of good reasons to use C++, not just Qt.
When mentioning C# "for gamedev", OP was probably talking about games business logic. The Unity core engine may be C++ (and assembly and shaders), but many Unity users / developers seem to do well with C# game logic / scripting.
EDIT question to Unity devs more experienced than I am: how frequent is it to "escape hatch" from C# to C++ game logic, in your experience? In what kind of game?
Had the occasion to watch a conference from a Dev in my company that would get rid of a lot of the overhead added by the Mono Behaviour in Unity. Getting better performances at the cost of less usability. In that case, one wonder why event bother using Unity?
For normal game logic I doubt the average user will ever cross that barrier.
C# in Unity can be blistering fast despite the GC if written correctly, and going to C++ still requires about as much (if not more) effort and knowledge as writing C# in a GC friendly way
> None of the options you mention, other than possibly Rust,is actually appropriate for game engines, systems programming, or embedded, due to the garbage collector
Rust doesn't have any sort of equivalent to ffast-math yet. :( I think their version (with 'fast' floating point types) would be nicer than the program-wide flags you get in C++ through the usual C++ compilers.
In general numerical-heavy code doesn't seem to be high on Rust's priority list (the math libraries are still fairly anemic). This is a shame, I would love to use Rust in anger!
It is and it isn't; that is, from a language perspective, the big thing here is type-level integers, which we accepted an RFC for, but is going to take some time to land due to implementation work being tough. It'll get there though!
As for a library ffast-math, it's mostly that we rarely hear people asking for it. I think that many people who want to do numerics stuff are waiting on the above; once it lands, I think more people will start writing libraries. Time will tell!
Nim is perfectly good for embedded. Also, GC is fine for the vast majority of systems programming. Finally, lots and lots of embedded programming doesn't need to be hard real-time. I'd wager that the majority of embedded projects are in C++ not because of any technical requirement but because the people in the field know only 1 language. (Note: I already addressed OS-less microcontroller programming in my top comment.)
I agree that I was wrong about gamedev, in the sense that popular game engines are also, currently, written in C++ (so play a role in keeping C++ alive by legacy, just like Qt does)
No, I haven't, and I am sure it is possible to do reliable real-time with those. It looks like all of those are commercial solutions (no open source).
I remember reading a paper about the IBM implementation (I assume that it turned into WebSphere). If I remember correctly, you still need to do some memory management like allocations up front compared to a "normal" Java program. Those guidelines seem a lot like what game programmers in Java end up doing.
I remember in college for a project that a team did a ping-pong playing robot in Java. It worked fine for maybe ~15 seconds then suddenly froze for a GC pause.
I need to remind people that Minecraft, a hugely popular game in the "real world", was originally written in Java. Not the kind of language you'd expect a game from. (I will agree that Java is probably not the right tool for the job though ^^').
This is the kind of thing where nobody will use it, until someone does. And proves the viability of the language. Nim has the potential to be a good gamedev language, but lacks the maturity.
Wishful thinking doesn't have a place in discussions on the technical merits of a technology.
It's like everyone is stating that the bugati veyron is the best car ever made and your only cobtribution to the discussion is making claims on how your flying car is way better.
You seem to be conflating technical merit with widespread usage. The wishful thinking was about some big success game using such a technology. The technical merits were already presented by GP. And they are real.
Besides, flying cars are way better. We need to keep looking into the future, otherwise we'll be stuck with what shitty technology we currently have.
None of the options you mention, other than possibly Rust,is actually appropriate for game engines, systems programming, or embedded, due to the garbage collector. There are still plenty of good reasons to use C++, not just Qt.