I think you've unfortunately got suckered in by Unity marketing wholesale, and things would stand to be cleared up a bit.

Unity's whole shtick is that they make something horrible, then improve upon it marginally. The ground reality is that these performance enhancement schemes still fall very much short of just doing the basic sensible thing - using CoreCLR for most code, and writing C++ for the truly perf critical parts.

IL2Cpp is a horror-kludge of generated code, that generates low-quality C++ code from .NET IL, relying on the opitmizing compiler to extract decent performance out of it.

You can check it out: https://unity.com/blog/engine-platform/il2cpp-internals-a-to...

The resulting code gives up every possible convenience of C# (compile speed, convenience, debuggability), while falling well short of even modern .NET on performance.

The Burst compiler/HPC# plays on every meme perpetuated by modern gamedev culture (structure-of-arrays, ECS), but performance wise, generally still falls short of competently, but naively written C++ or even sometimes .NET C#. (Though tbf, most naive CoreCLR C# code is like 70-80% the speed of hyper-optimized Burst)

These technologies needless to say, are entirely proprietary, and require you to architect your code entirely their paradigms, use proprietary non-free libraries that make it unusable outside unity, and other nasty side effects.

This whole snakeoil salesmanship is enabled by these cooked Unity benchmarks that always compare performance to the (very slow) baseline Mono, not modern C# or C++ compilers.

These are well-established facts, benchmarked time and time again, but Unity marketing somehow still manages to spread the narrative of their special sauce compilers somehow being technically superior.

But it seems the truth has been catching up to them, and even they realized they have to embrace CoreCLR - which is coming soonTM in Unity. I think it's going to be a fun conversation when people realize that their regular Unity code using CoreCLR runs just as fast or faster than the kludgey stuff they spent 3 times as much time writing, that Unity has been pushing for more than a decade as the future of the engine.

The biggest issue is that Unity is at the same time, the farol beacon for doing game develpment in C#, that Microsoft refuses to support, see how much effort Apple puts on game kits for Swift, versus DirectX team.

Efforts like Managed DirectX and XNA were driven by highly motivated individuals, and were quickly killed as soon as those individuals changed role.

One could blame them for leaving the project, or see that without them managemenent did not care enough to keep them going.

While at the same time, since Unity relies on such alternative approaches, it also creates a false perception on how good .NET and C# are in reality, for those devs that never learned C# outside Unity.

In a similar way it is like those devs that have learnt Java in Android, and get sold on the Kotlin vs Java marketing from Google, by taking Android Java as their perception of what it is all about.

Going back to game development and .NET, at least Capcom has the resources to have their own fork of modern .NET, e.g. Devil May Cry for the Playstation was done with it.

"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"

https://www.youtube.com/watch?v=tDUY90yIC7U

This part of your comment is wrong on many levels: "The Burst compiler/HPC# plays on every meme perpetuated by modern gamedev culture (structure-of-arrays, ECS), but performance wise, generally still falls short of competently, but naively written C++ or even sometimes .NET C#. (Though tbf, most naive CoreCLR C# code is like 70-80% the speed of hyper-optimized Burst)".

C++ code is much faster than C#, but modern C# has become a lot better with all the time that's been invested into it. But you can't just take a random bit of C code and think that it's going to be better than an optimized bit of C#, those days are long past.

Secondly, the whole point of Burst is that it enables vectorization, which means that if you've converted code to it and it's used properly that its going to support instructions up to 256 wide (from what I remember it doesn't use AVX512). That means that it's going to be significantly faster than standard C# (and C).

If the author is generating for example maps and it takes 80 seconds with Mono, then getting to between 10-30 seconds with Burst is easy to achieve just due to its thread usage. Once you then add in focused optimizations that make use of vectorization you can get that down to probably 4 odd seconds (the actual numbers really depend on what you're doing, if its a numerical calculation you can easily get to 80x improvement, but if there's a lot of logic being applied then you'll be stuck at e.g. 8x.

For the last point, new modern C# can't just magically apply vectorization everywhere, because developers intersperse far too much logic. It has a lot of libraries etc. that have become a lot more performant, but again you can't compare that directly to Burst. To compare to Burst you have to do a comparison with Numerics, etc.

While I get that you’re making a stylized comment, it’s a big drag. It’s one of those, “everyone is an idiot except me” styles. By all means, make a game engine that people will adopt based on CoreCLR (or whatever).

It’s not saying much that everything has tradeoffs. During the “decade” you are talking about, CoreCLR didn’t have a solution for writing anything for iOS, and today, it isn’t a solution for writing games for iOS. What you are calling kludges was ultimately a very creative solution. Usually the “right” solution, the nonexistent one that you are advocating with, ends with Apple saying no.

That is why Unity is a valuable piece of software and a big company: not because of C# runtimes, but because they get Apple and Nintendo to say yes in a world where they usually say no.