(accidentally replied privately instead of to the list; I really don't get why "reply to list" isn't usually a thing; it should be the default when replying to a message from a list) On 9/13/18, John john.r.moser@gmail.com wrote:
Also, there's not necessarily a performance penalty in CLR because it's JIT to native code. The CLR isn't actually interpreting bytecode as it goes; rather it's compiling the program, storing that compiled program in memory, and entering the compiled native code. The outcome is the same as compiling a language to a native machine language.
It's certainly closer to native code than a pure interpreter in performance and may be comparable in some situations, but I was pretty sure that the overall performance was still somewhat weaker, especially when you're dealing with real-time code.
I designed a way for the CLR to self-host: it'd be written in C#, and running on itself. This is still theoretical, of course.
I'd think you'd have to statically compile it to native code first.
To me, language-based OSes have always seemed interesting but a bit impractical and limiting. A language-based OS would face more of a challenge when it comes to success in the real world than a conventional OS would (that's one reason why I'm writing an advanced Unix-like OS, since that is what is most likely to be used in the real world).