"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#."
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.
Mentioning C# for gamedev and the topic being about GUIs, makes me wonder if he was talking about tools? C# with WinForms are very popular for creating tools in game studios (if you notice tool screenshots from presentations like GDC, you'll often see the telltale marks of WinForms - like the gradient menubar, the default icon, the extra padding around some elements, etc).
Nah, I was just wrong about gamedev. I genuinely believed that all modern engines were mostly programmed in C# but people in this thread corrected me. It's just the game logic scripting.
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.
No, they are not.
If you want to get into some industries you have to have track record of decades of backwards compatibility. Those two languages don't have that.
C# is actually "Unity script" and compiles to C++. It even bundles its own C++ garbage collector.
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).
Lol I just opened unity, and can't use null coalescing. I say unity script because it all compiles down to the same IL. Where did I say you can't use async/await. It's not "real" C# in the sense that you don't get the .Net runtime.
I don’t care if you abhor Unity, I just particularly dislike FUD on HN. People tend to hold what people write in a slightly higher light and assume a professional is speaking... not a guy who thinks “you need the newest version” is a disqualification for a feature list.
Jeez well I've been an engine developer for 10+ years so if you want a professional that's me. Comparing the source code and functionality of Unity to, say, Unreal 4, there's just no comparison. (edit, and let's not count all the custom engines I've been exposed to or worked on)
> 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.
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.
I'd say the term "weird filter bubble" fits your ideas of embedded -- attiny or running linux, with nothing in between -- far better than it fits the HN idea of embedded.
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.