[nonsince]

C# is, among GC languages, particularly bloated with regards to memory. There is huge amounts of runtime type information (including stringified versions of everything) and you have close to no control over memory management without hooking into ugly APIs. I wish that Swift or Rust had been usable early enough to get swept up in the hype train so that we could avoid this crap. Also, it would mean I didn't have to use OOP to write games.

[golergka]

C# specifies the language, not the runtime. Apart from .NET and Mono, you can compile C# to cpp (what Unity does under the hood, btw).

> Also, it would mean I didn't have to use OOP to write games.

There are many instances where other programming paradigms are more usable - but in my experience, gameplay logic, specifically, maps very well onto classic OOP concepts.

[nonsince]

If gameplay mapped well onto OOP then the big game companies would use it, and not data-driven programming (specifically, entity-component systems). I think that there are a couple things that require OOP-style dynamic dispatch, but they don't need to be pervasive, even a function pointer stored as a struct member is more than enough to provide all the benefits of OOP without having to take on all the drawbacks.

[jameshart]

You should take a look at what is going on in the latest dotnet core CLR and C# compiler around 'ref-like' types and Span<>s. Basically a way to let you write 'safe' C# code that interacts with memory that is allocated in different ways (for example with controlled allocation outside of the GC).

Since C# is a multiparadigm language with strong functional as well as OO fundamentals, I suspect it will make it possible for libraries and frameworks to be built which enable allocation free code in C# gameloops. It's not just game engines which have these requirements - the same functionality is also critical for high performance servers, and machine learning applications, so this is a language feature with a lot of demand.