The same was said about the game developers using Pascal and C instead of Assembly, followed by game developers using C++ instead of C.

The industry always needs some pioniers willing to do the investment regardless of the naysayers.

Note that the game industry avoided C++ for a long time because those early C++ compilers produced code which was very large and quite a lot slower than you'd get from C, so C++ was kind of a non-starter when you were writing code for the consoles of the day which had slow processors and only a few megabytes of RAM. You just couldn't afford the overheads of C++ or your competitors would eat your lunch.

It wasn't about needing a pioneer to show us that we'd been wrong; we weren't wrong. C++ just wasn't ready for the particular set of requirements that games imposed, yet. Once the state of C++ compilers began dramatically improving in the late 90s (by the criteria of optimisation and executable sizes), most studios moved over to the language pretty quick. Or at least that was my experience.

The pioneers were the studios using Watcom C++ on MS-DOS, while others were still being dragged into Windows with plain old C, while complaining about losing hardware access until Wing was released.

And the studios that were forced to adopt C++ when the PlayStation SDK required it.

So nothing speaks against other languages getting over the same kind of acceptance issues.

I am not a naysayer. I just point out the resource investment involved in going down a different path.

Also, Unity is built on a lot of 3rd party C++ code. From the top of my head, this is at least Mono, FMOD, PhysX, Enlighten and FBX.

Sure, just like those C and C++ engines weren't re-writing the battle proven Assembly libraries unless required to do so.

Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.

Unity makes it very clear in their blog posts that Burst is a special vectorizing compiler. It is not a linter at all. I am not sure where you got that notion.

IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming.

Compare all this to Unreal. By sticking to C++, they do not have to commit the same amount of resources to programming language related tooling.

Burst is basically an upgrade to Roslyn with some perf warnings set to errors.

IL2CPP is literally required on iOS but the perf gain you get on Android was never very good. Because of its general instability, a lot of games just ship in mono mode.

It's funny that you're saying both Burst and IL2CPP are required. Can't you see that Burst is an admission that IL2CPP wasn't the way to go?

Actually they do, because Blueprints need to support graphical debugging and profiling as well.

Some studios don't want to mess that much with Unreal's C++.

Then Unreal has their own C++ runtime to allow for a tracing GC.

Still, Epic does not have to commit the same amount of resources. That is my point. The Unreal Build Tool and Unreal Header Tool do not come for free, but this is still less than two sets of optimizing compilers in my book.

IL2CPP resuses the platform C++ compiler, and Burst builds up on LLVM.

It is not like Unity is building their compilers from scratch.

And the fact that the Insomiatic guys felt it was a good project speaks for it, given how they are respected in the gaming industry regarding engine optimization.

Also some of this work influenced C# 7.x features.