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.

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

Are we collectively forgetting Unity3D?

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

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

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.

They are in the process of adopting .NET 4.6.

IL2CPP is no different from CFront.

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

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