I agree. Moving things to C# reduces interop overhead and I think it's the right direction. If you don't want to look at engine code, don't. Why does anyone care it's in C# if they're not looking at it anyway?
> Why does anyone care it's in C# if they're not looking at it anyway?
Garbage collection probably. Some games have noticeable stutter. But I assume there are ways around that, similar to using Java in HFT.
A lot of effort goes into making sure allocations are avoided though. You also have DOT's High Performance C# which is a blazing fast subset of C# (Burst Compiler). I like the idea of using a language for everything, then restrict to a subset where performance is critical. You don't have that wall between scripts and (C++) engine code. And as mentioned above, less glue code is appreciated.
This is going to sound insane. But I am developing a perfectly good putt putt game with unity 2018 lts on a 12 year old laptop with 128 Meg video card. It's slow but builds work great. So far. For learning and small games it works well so far. And has a load of tutorials made recently by youtubers. But it is a bit confusing to work out what to use and what is to old to use code wise.
I love that they are moving more and more stuff in C#. It's a good thing. The C# code is available for developers to view and modify, but no one is forcing you to.
The problem is that a lot of Unity's early choices that made it so accessible to novice game devs making simple games, made it to inflexible or slow for bigger or more complex projects.
If you were building a high performance procedurally generated game, you were already fighting with all of the "easy stuff".