We're supposed to interpret other comments in the most charitable way, but a charitable interpetation is not at all possible when one says that C# is a usable solution for systems and embedded programming, that Nim is mature, or go is used in games and is a good idea to use for embedded.
Even combining all of the above languages would not reach the breadth and maturity of C++ in the target domains.
Sorry, you were pretty much wrong in every claim. None of the options you've mentioned are actually stable with the exception of C#, which you already acknowledged that were wrong to mention.
It might only be one engine but it’s a juggernaut in the industry
It's terrible. Not being able to write native code is a tremendous weakness of the engine. Not to mention that since you're writing a "fake" C#, you don't get the full runtime (can't use reflection, can't use coalescing null features, etc).
Unityscript is the Js clone they have/had (they’ve been pushing for C# to be the main language).
You can use null coalescing.
You can use all of Reflection bar platform restrictions on AOT ie. iOS (don’t recommend it in a game though...)
You can use a async/await.
You’re writing “real” C# with Unity, either with a custom Mono runtime or IL2CPP, neither of which turns your C# into “fake” C#
And Unity3D is “terrible” enough to serve 700 million players.
Then learn the settings and limitations for your target platform.
Just because you don’t know how to use Unity doesn’t make it doesn’t have features it does.
Look, just because I abhor Unity doesn't mean you have to take it personally.
Now you’re waving your hands and saying “So what I was wrong, Unreal has code, it has the best code”?
I think we’re done here.
IL2CPP is no different from CFront.
Unity devs could have gone full way and implemented a compiler backend themselves.
Instead they decided to take advantage of the SDK present in every target platform they support.
C++ once upon a time, also got compiled by generating C code.
Then don't misquote me. I didn't say any of that, except perhaps implying that Nim is mature. Ok right, and Go is great for embedded. I worked in embedded systems for years. 80% of the software ran on little arm boards that ran a decent OS (eg QNX, Linux, etc). Go would've saved so much trouble there. There's this weird HN filter bubble attitude that if it's more than 20MHz or does not ship with a 15 year old GCC fork, then it's not embedded, but that's bullshit. Go is a fantastic option for a very large amount of embedded software, and I'd wager what's left after that is perfectly served by tiny C programs running on little atmels.
I explicitly singled out C# for gamedev. Look, I'm trying to make a general argument that a few large still-good legacy libraries (such as Qt) are the only reason C++ is still standing. I must admit it feels a little like you're trying to misunderstand me on purpose because you don't like the message.
Yes, Qt is the only pure C++ cross platform GUI with high quality tooling.
However on Windows there is still UWP, mostly written in C++.
What is happening is a shift of focus, instead of doing a full app 100% in C++.
C++ gets used where it is best, low level high performance library code, with higher level code being written in a safer language.
So while the app developer might stick with Swift, Java, Kotlin, Web browser, .NET, there is still a C++ layer underneath.
For example, Metal shaders are written in C++14.
Also IoT has given a big push to C++, Arduinos, ESP286, ESP32 kind of devices are mostly developed in C++.
So yeah, there are still a couple of decades of C++ on native GUIs, if nothing else, pushing pixels around.
Sure. But what about, e.g., gtk?
Also they are mostly focused on being a good UNIX toolkit.
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.
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?
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
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!
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!
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)
Even soft real-time can be difficult with a GC in my experience. You end up doing all kinds of hacks to workaround the GC.
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.
The GC is optional. It's also configurable and there is a realtime garbage collector, too.
Finally there's also region based memory management.
Some people might have some GitHub repos with games and game engines written in Nim.
Some people might have even shipped some second tier game written in Nim.
Then again, hobbyists will use anything.
But virtually nobody had used or uses Nim to create any kind of game or game engine that is behind any successful game in the real world.
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.
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.
No C++ isn't unproductive. Go and C# is NOT FAST OR SUITABLE FOR GAME DEV (AAA in particular but even lighter games. You'll pry manual memory management from me from my cold dead hands). Maybe you mention C# because it "powers" Unity? Guess what, it compiles to C++ through the IL backend. Other languages haven't figured out cross-platform. And I don't mean Mac and PC. I mean Mac, PC, iPhone, Android, Linux, Playstation, Xbox, etc. People keep writing about C++'s demise, but I don't see them writing LCP constraint solvers in other languages successfully. I will submit that of the things you mentioned, Rust and Nim are closer to the target since, at least, they don't run on this slow as molasses runtime (slow in game terms), but they are extreeeeeeemely immature, and you're talking on porting very complex problems. No thanks, I'll take the thing that has an actual standards committee where I can determine exactly how to control or tweak things at whim.
Basically, this type of comment is always a cheap shot to get upvotes but simultaneously always misinformed and from someone without actual game development experience.
This is of course, far from the ease of official vendor support.
There are many valid uses for C++, however using IL2CPP as an example, well that is just an implementation detail of their C# compiler.
If Unity would be willing to spend the money, they could have implemented a compiler backed instead.
With GC languages, one just needs to learn about value and reference types, and which language features might implicitly allocate. Which can be helped via static analysis.
Regarding .NET specifically, there are quite a few ways of doing manual memory management, although not as fine grained as C++, which many devs seem to be completely unaware of.
In both scenarios, using a profiler is a must have for anyone caring about performance.
And lets be real, unless one is competing with AAA level games, there is a big spectrum of game styles that don't need the ultimate hardware performance, just good enough for an enjoyable game experience.
That's not how the industry sees it. Almost nobody does those things in Rust, Go, Nim and C# (except if you mean second tier not AAA games done in Unity and co).
And by nobody I mean less than 1% of those that deliver those kinds of solutions use those languages.
Regarding gamedev: Unity itself is still written in C++ and Unreal Engine uses it even more. AAA games are written mostly in C++ with Lua/C#/Python for scripting.
There are still a lot of other reasons to use C++, too.
"A hundred companies" is both good and bad, of course: that's a drop in the bucket compared to C++. It's also not nothing.
A talk at FOSDEM 2018 about that is here https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...
Back in the 80 and early 90's, languages like C, Turbo Pascal, Basic,.... where the scripting languages, with the core implemented in Assembly.
Then the ladder moved up and they started to be used to implement the engines.
Same happened with C vs C++.
Now we are on the C++ vs GC languages phase.
C++ won't be gone from the pixel pusher and real time audio layers for a long time, but the other layers willl eventually use something else.
But none of those languages have Qt. Of course, there's stuff like PyQt which is nice, but it's not got the status that C++ has in Qt land. Really what I'd love is if Qt would add first-class support for one of those newer languages. Rust maybe? I reckon it's a enormous, maybe simply unfeasible undertaking, but first-class Rust support, so I can fire up Qt Creator and start coding Qt apps in Rust would be fantastic. It would suddenly increase the usefulness of Rust by enormous amounts and it would keep Qt relevant.
Does anyone know if the Qt people are evaluating other languages? Are they worried, commercially, about C++'s demise?