Hacker News Reader

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

Are we collectively forgetting Unity3D?

It might only be one engine but it’s a juggernaut in the industry

...and is often used by translating IL code to C++, if I remember a recent cppcast episode correctly.

Yes, but that is an implementation detail.

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.

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

They are in the process of adopting .NET 4.6.

IL2CPP is no different from CFront.

Pardon my French but you’re talking out of your ass.

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.

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.

Update your Unity3D version and learn how to set your .NET runtime.

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.

Yes it's on the latest version and you can't set the runtime when targeting certain platforms.

Look, just because I abhor Unity doesn't mean you have to take it personally.

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)

I guess I’m glad you’ve taken 10+ years to come here and be wrong about something this simple.

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.

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.

> Nah, I was just wrong about gamedev.

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.

Go and Rust aren't stable?

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.

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

C++ isn't going anywhere for the foreseeable future.

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.

> Yes, Qt is the only pure C++ cross platform GUI with high quality tooling

Sure. But what about, e.g., gtk?

Gtk+ is a C toolkit, and regarding tooling, Glade isn't as feature rich, both Builder and Anjuta are just ok IDEs.

Also they are mostly focused on being a good UNIX toolkit.

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

From my experience, not that frequent.

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

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)

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

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.

Have you experience with the likes of PERC, JamaicaVM, WebSphere Real Time?

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.

Actually Nim is used for games and game engines.

The GC is optional. It's also configurable and there is a realtime garbage collector, too.

Finally there's also region based memory management.

https://nim-lang.org/docs/gc.html

https://forum.nim-lang.org/t/2489

>Actually Nim is used for games and game engines.

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.

Yet.

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.

> Yet.

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

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!

A reasonable question, but the reality is that C++ is the ONLY choice for certain fields (basically anything where you need a high-performance "engine" under the hood). Finance, gaming, databases, etc.

I'm a bit allergic to proclamations of C++ obsolescence but to be honest I'm finding myself using it less and less myself. Not sure I agree OS-less micros are best done with plain C, though. A lot of programmers are put off by the latest C++ developments but it's very possible to use C++ to great advantage even in tiny environments. You just have to really know what you're doing.

I see this sentiment all the time and the answer is "nooooo." It's honestly getting frustrating, and I tire of writing the same apologia.

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.

Just like C++ used to be compiled to C.

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.

The usage of a GC changes the nature of the solution entirely. Say you wanted to write a bullet hell game. Spawning bullets/spells in the thousands takes pretty careful management and without memory management, understanding where you've leaked or why memory isn't being reclaimed when you expect can be nightmarish.

Same applies to malloc()/new, no one on their right mind would be allocating during the hot path of rendering loop.

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.

Incidentally, apparently getting Rust running on consoles is fairly easy, see https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...

This is of course, far from the ease of official vendor support.

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

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.

PyQt seems to work quite well, for example fman is written in it: https://fman.io/

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.

Show HN: Cross-platform desktop applications with PyQT | https://news.ycombinator.com/item?id=16318677 (yesterday)

Paying customers for Qt are still very C++/C oriented. Qt goes where the money is, and it seems to be in contracts with large manufacturers and focus in embedded systems, especially the automotive industry, automation and digital television. The QNX and INTEGRITY support is big deal in many industries.

Isn’t it a truism though that the existing customers for a C++ tool will be very C++ oriented? Surely the real question is where is the potential growth, and future customers.

I'm sorry but I disagree. Mature Rust is not the same as mature C++. If you are a commercial entity you would, in my opinion, be fool-hearty to select a language like Rust, mature in the sense you mean or not, as the main language of use. Or at all quite frankly, for the single reason that it is more difficult to employ quality people as the talent pool to draw from is far too small. And it is also the reason I never invested myself to learn it, for its technical merits or not.

Over a hundred companies, including some big ones, disagree with your opinion here: https://www.rust-lang.org/en-US/friends.html

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

Just to clarify, I agree, it's not nothing. But still.

Rust and C++, esp how Qt uses it do not mix very well in my opinion. For that reason I created tool to create bindings rom a JSON model to both Qt and Rust. You write the application logic in Rust and the UI in Qt.

A talk at FOSDEM 2018 about that is here https://fosdem.org/2018/schedule/event/rust_qt_binding_gener...

Rust isn't that mature for games, ditto with Nim, Go is ok but has a GC, C# is too slow but OK for scripting, but then again lots of languages can be used for scripting. C++ isn't going anywhere in the game development world for now. Maybe something like Rust will upend it someday, but not yet.

I agree, but it is also a matter of hardware resources.

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.

It'd be interesting if Qt had something like Vala for GTK

Look into QML : http://qmlbook.github.io/en/ch04/index.html