I know hardcore embedded people will hate this idea, but sometimes you have to take the massive performance and memory hit to tempt developers in who prefer to get stuff done with powerful libraries than learn a new language and start worrying about memory management...
Memory management is just as automatic as well (they seem to just be using the mono runtime).
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.io.memory...
[1]: https://docs.microsoft.com/en-us/dotnet/api/system.threading...
[2]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...
[3]: https://docs.microsoft.com/en-us/dotnet/api/system.globaliza...
[4]: https://docs.microsoft.com/en-us/dotnet/api/system.net.http?...
Except heaps / priority queues, which always irked me because it's in the Java standard library :-(
That being said, there are plenty hobby (and commercial) projects where .NET is perfect.
Most microcontrollers today don't even have cycle-accurate memory access guarantees, so it's impossible to do timing more accurate than tens of nanoseconds.
Things requiring low latency and accurate timing always end up hardware assisted (USB controllers, PWM hardware, UART serializers, and a million more examples).
Likewise .NET's support for value types and low level programming also means not everything needs to be GC-allocated.
Most people don't have those kinds of performance considerations. I use C# for soft realtime all the time, but in the instances when I have done actual realtime embedded work, I just used C.
Many pipelined architectures do not define in datasheets exactly what can cause a pipeline stall - usually they provide rough guidance, but not information about corner cases. Branch prediction likewise is rarely fully defined in the datasheets.
Some architectures have some operations which are data dependant - for example, "division takes 6-8 cycles". The software developer can't be sure it will be 6, 7, or 8, and if they were to measure performance, they'd be relying on undefined performance behaviour, since a new revision of the same model of chip could change performance.
Also, most architectures with DMA aren't cycle accurate because the SRAM is single-ported, so you get a CPU stall if you happen to read memory in the same cycle as a hardware device needs more data.
I write VR apps in C# for a living. Avoiding the GC is not that hard.
The thing is most methods for avoiding GC are just round about ways of doing manual memory management. And games are soft realtime, so a dropped frame every now and then is generally acceptable.
Also look at the new Unity DOTS stuff. They are building their own high performance subset of C# where memory layout and data locality are first class concerns and adding in mechanisms for manual memory management.
It's not really "round about ways of doing manual memory management". You can heap-allocate as much as you want, as long as you aren't doing it in a critical hot path. Object pooling is good practice, regardless of language and runtime, for real time anything. I do my major allocations and deallocactions during scene transitions, where the view is faded out already because making visible scene transitions in VR is nausea-inducing on its own.
And from a project management perspective, I've found it best to avoid using as much of Unity's built-in stuff as possible. Most of what they create are just garbage reimplementations of stuff that already exists in the .NET ecosystem.
I'm long-term going to get off of Unity. I'll eventually be building my own system on top of Xamarin, as I excise more and more of Unity out of my projects. I've already had to code my way around so many of their systems just to make quality apps that don't hiccup when things load that I don't really have a lot left to do.
All of the VR vendors provide C APIs for interfacing with their systems, which are the actual, first-class systems. Providing a P/Invoke layer on top of that won't be too hard. And Xamarin already provides wrappers around ARKit and ARCore.
Shader-wise, there's not enough processing budget to do anything but very basic shaders that I already know how to write, anyway. Any of the more advanced shaders that work well in VR are open-source.
Light baking can be done in Blender directly.
Unity's Audio pipeline is really bad. I have 50% of a reimplementation already. And again, spatialization is provided by the VR vendors, so there is very little of Unity's own code running in my audio systems anymore.
Sure, I wouldn't have learned how to do all of this stuff if I hadn't started with Unity, but once you get into trying to build scalable apps with pleasant user experiences, you have to ditch so much of Unity's built in stuff that it starts to look less and less like a good value proposition to continue to put up with the rest of their stuff, considering how buggy it can be.
So many things in C# use heap memory that you are programming in C# but without most of the advantages. Why use it over C++ or C?
Also if you take a look at DOTS, there's quite a lot that would be very hard to replicate yourself if you are using Unity.
And yes object pooling is a good best practice. But it negates a lot of the advantages of having a GC in the first place, and it's a lot easier for someone to accidentally allocate memory in C# without realizing it. Unity has a lot that I take advantage of, so I deal with avoiding GC. However if I was using my own engine, I wouldn't use C#. Despite the fact that I love C#.
There are many games in C# that even run on iPhones and are very performant.
There's also LING for Erlang on Xen which isn't supported much but some still use it.
There is also MicroPython and CircuitPython.
Embedded people are very happy about any new languages coming to our hardware. Especially when it brings in new people, i.e. CircuitPython is a great tool for beginners.
But there is also severe limitations with these interpreted/bytecode-vm languages. MicroPython i.e. takes a 100x performance hit. And you need beefy big controllers.
There however a lot of situations where they are usable, and in in those cases, it's really great and fun to work with.