every so often there will be always somebody trying to make a hobby OS that outright ditches native code and uses exclusively bytecode for the programs running on it... Not sure if that actually ends up happening in practice.

Android?

Sure, the kernel, the Dalvik VM, and some low-level functionality is written in C/C++, but pretty much everything else is in Java. Of course, game developers kvetched till they were given access to native code, but that's neither here nor there...

Well, it gets jitted, and cached usually...

Still, android is a damn slow platform most of the time, its very annoying. Someone went through and rebuilt the OS with pre-jitting etc. and it was significantly faster than the one that normally ships on phones.

Mind you, its not a problem with JIT or interpreted languages or anything like that. Its simply that JIT + embedded systems don't really go hand in hand very well (they work, but its usually not the best...idea).

This last discussion reminds me of how every so often there will be always somebody trying to make a hobby OS that outright ditches native code and uses exclusively bytecode for the programs running on it (though generally it gets JIT'd at load time to prevent the massive performance loss).

I would absolutely love to see a useful top half ISR written in an interpreted language, even if it's JITted at runtime.

I guess the idea would be an OS kernel written in a native-targeted language like C, with a user runtime written in an interpreted language.

In the end, I'd prefer if we could get a language that gives the control of C/C++ and the convenience of the higher level languages. I actually think it would be worthwhile to put some of the energy that's being spent on updating C++ into just developing a whole new language that gives a closer approximation to that blend. When I can get something that's very easy to code in and highly portable, but manages to be clear enough that I can predict what the native bytecode will look like, then I'll feel like we're making progress.

Actually, the Ada programming language predates the C++ language. It's lack of widespread success was due to the combined factors of tight centralized control (no vendor variants were allowed, so you could not get a subset for DOS) and the lack of underlying hardware support for some of its mandated features (for example, support for concurrently on processors that did not provide atomic operations). Oh, and it's incompatibility with existing libraries written in C.

It was like being handed the keys to a brand new Cadillac but all you had in your garage was a Vespa. Everyone rode their Vespa, and now people are debating about whether it's better to ride a Vespa or a Honda. The Cadillac is still out there, rusting away.