Better is relative. And it's just a different type of tool. To be honest I know many more better engineers who primarily work with dotnet over CPP. The learning curve for CPP is higher because the ability to shoot yourself in the foot with CPP is higher. It's neither better or worse. Just a different tool in a toolbox.

I think a lot of people find the learning curve of c++ fairly extreme, especially when considering the amount of knowledge to do idiomatic programming in c++ required to “do things elegantly.” C# and related languages tend to have idioms baked in closer to the syntax and grammar. My view of c++ after 30 years of it is it’s great if you’ve got 10 years experience programming it within a team of seasoned c++ programmers who shows you the ropes. Even then I think rust is the language I wished for all these years (albeit not for game dev yet). Finally, for the reasons rust isn’t great for game dev, c# and ilk generally have excellent reflective and dynamic natures making them sort of the sweatpants and old T-shirt language for game programming.

That said, it locks you into using stuff like mono and stuff for cross platform which makes me a sad.

> That said, it locks you into using stuff like mono and stuff for cross platform which makes me a sad.

Microsoft's .Net Core runtime (now just .Net) has supported Linux and MacOS since 2016, so this information has been out of date for 7+ years.

https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...

Oh thanks! I stand corrected. Good to see.

But that does NOT include WinForms.

Define "better language". If you don't need performance then C# can make your life much easier.

The new versions of C# can compile ahead-of-time, and have expanding support for value types and pointer-like semantics, so you're not stuck with the Java-y OOP For Everything paradigm if it doesn't fit your requirements.

The standard libraries are still an allocation party, of course, but that can be supplemented in an engine context.

Famous last words, even with the optimization in the latests net core clr, it's nowhere close to C++.

Citation needed? Raw speed is likely similar; the cost overhead comes from GC cycles and the general approach to managing memory primarily in the heap vs stack, although C# can stackalloc if you're really diligent. Note that this is the same problem that blazing fast alternatives like Go have at competing with C/C++. These languages are mostly equivalent to C/C++ in speed, but lose the benchmark shootouts because of GC.

Calling Go blazing fast would be a stretch at best...the path to performance in C# is same as in Rust or C++: struct generics (aka templates), as short hot paths as possible, static partitioning of the work, sometimes hands on memory management and minimization of locking.

This is a pretty wild generalization to make. It's not hard to contrive scenarios where C++ with its notoriously slow stdlib (despised by game developers) is going to be slower than C# with its JIT doing runtime optimizations like guarded devirtualization.

C++ written by people who really good at writing fast C++ is faster than C#. Naive and readable C++ written by average programmers wanting to solve a problem in the obvious way on the whole isn't faster than C#

Keep in mind that in addition to the "learning curve" arguments, there is also the functional developer ergonomics of things like live reload (where you can maintain memory state) that are simply not possible to do with C++ without heavy limitations or customized tooling.

Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development where generating the right memory state can be incredibly complex and depend on a ton of very specific and hard-to-reproduce factors. Not to mention incredibly slow.

"Being able to fix a bug without resetting memory state is a huge ergonomic advantage in game development"

Visual Studio works with UE and calls that "Edit and Continue" and it works in C++, too.

Yes, but it has many known limitations and isn't nearly as reliable as a runtime that has a full GC and virtualization optionality, which you really need in order to fully track what state can be evicted and what needs to stay.

Game devs want fast iterations above everything else, with performance being a close second. c++'s "toolchain" makes those iterations prohibitively impossible, even with decades of workarounds with hot reloading and extravagant methods to keep compilation times down.

If you're a AAA dev you give up a lot of that iteration because performance overtakes you, but there's little reason some indie 2d platformer will want to deal with even 30 second iteration times (which would be blazing quick for a AAA setup). C# is a mature, familiar environment for devs with similar syntax to C++ that can get decent performance as long as you maintain some discipline (for starters, no LINQ)