This is just not the environment a memory managed language, running atop a virtual machine runtime is suitable for. You'd have to strip all that away, and then you'd just be left with C# syntax, but it would be very far from being C# and would not be compatible with any standard C# library, framework or platform.
For a lot of embedded work, even Rust is having a difficult time getting traction. Even the C++ Standard Library doesn't fit on many of the systems folks are working on, let alone the STL.
The system I'm working on at my day job has about 1meg of Flash and, IIRC, 128k RAM. It was reduced in resources to save cost (disposable device). The one I'm working on at home has about 4M Flash and 256k RAM. One of them is making liberal use of the STL and I know both have Python implementations available.
Tiny, memory constrained devices are still around, but they're a smaller and smaller part of the pie every year.
The performance ceiling of C# is extremely high now though, if you use the low level features. Unsafe blocks, even simd intrinsics! But at that point you aren't really doing C# so much, but at least you can dip into those features for performance critical parts of your code without having to pull out a new language and compiler and complicate your workflow and build tools.
I wouldn't really agree on this point.
Unsafe blocks have been a feature since C# 1.0 They may not be the default way of writing C#, but they've always been a natural and integral part of C# and have extensive use internally to ensure that interop can work and extra performance is available where possible.
SIMD acceleration has likewise been a part of the BCL (standard library) for nearly 10 years now and is just as integrated behind the scenes. It being part of the formal BCL makes it even more "standard" than the equivalent in C/C++ where such functionality is relegated to compiler specific headers/extensions.
SIMD code itself is also very idiomatic C#. There is nothing really different about utilizing the APIs, the only difference is in how you think about handling your data. Needing to think differently about how data is handled for some contexts is applicable to many domains in C# (and programming in general). It's no different than making code work with async or multi-threading ;)
Simply put, all these features are still C# and I don't think its necessarily good to say that using them means you're not really writing C# anymore. I view it as a disservice to the language, its extensibility, and power. It also leaves a connotation that you might be better off writing C/C++ instead, which is often not the case.
Now we take multi-core, 64-bits, gigabyte address spaces, memory protection and multi-tasking Unix-like OSs for granted most of the time. Except for the most stringent requirements (such as hard real time or very constrained power budgets) that we find small bare metal platforms.
And those are real fun to do ( but not as much fun to debug).
I specifically left embedded out because I didn't really want to make assumptions about CLR byte code running within the constraints of such environments. I've only ever programmed in C++ on embedded devices, so I can't actually comment on CLR (ergo the perhaps in my comment).
It is actually a pretty nice framework, but it does (did) require a 32bit CPU at minimum, and a hefty amount of flash.
That said, the UI framework was a joy to work with!
I should do some sort of write up of just .netMF, but I don't honestly recall too much about it in a general sense, since most of my time was spent in the weeds optimizing code.
I'm terrible at clickbait titles, so I sadly don't see much hope for future articles achieving any significant level of popularity!
any
use case (except perhaps embedded) with .NET.
How so? Do you mean it doesn't support ephemeral ftrace-based tracing or something? That seems unlikely to be true given core CLR features like reflection as well as Microsoft's extensive history of embedding .NET into services and devices.