> Why can “we” write pretty good apps in languages other than C, but can’t write operating systems? Is talking to hardware so much different than talking to APIs?
Operating systems are written in other languages, such as C++ and Rust.
One requirement is that a language must be compiled and thus cannot rely on a runtime. That excludes Go and Java.
The language needs to support direct memory manipulation.
The compiled binary cannot be emitting system calls since that binary IS the kernel. Thus the compiler must be told to not link or include standard libraries.
You need to disable certain optimizations like advanced vectorization extensions and red zone use on the stack.
There are others. Lots of specific control needed.
This is why rust is so exciting: it's the first new language that's graduated from toy-language space we've seen in a while without a runtime. (python, ruby, go and typescript-nodejs are the other graduates I'm thinking about.)
>One requirement is that a language must be compiled and thus cannot rely on a runtime. That excludes Go and Java.
Maybe I'm wrong, but I know that there exist CPUs made specifically to natively execute Java bytecode, so in reality if the hardware has a baked-in language interpretation it would be actually possible to write an OS completely in Java
True, you can design a CPU for anything. However a OS that depends on such a CPU is not portable to anything else, and can't easily run most programs that people depend on (emulators are possible, but not easy). Also most CPU advances haven't gone into such a thing and it is tricky to apply those advances while also providing what the language needs. None of this is impossible, but it makes such CPUs in todays world of questionable value.
Note that you can port any OS written in C to such a CPU with "just" a new compiler backend and a few drivers. Your OS won't take advantage of the features the CPU provides, but it will work.
running java bytecode natively is neither necessary nor sufficient as you can compile java to any other native ISA, but you do still a relatively heavy runtime for GC.
Having said that, there have been OSs written in languages with heavy runtimes, even GC.
I was answering the question in a general sense for the more prolific operating systems and on generic commonly available general-purpose processors.
Yes one can implement a CPU that natively executes a runtime for a high-level language, make your own ASIC, or FPGA, etc. that does this. That is a more advanced response to the general question.
Knowing the detailed points I mentioned will help understand why specialization of processors is needed to support other higher-level languages that do not meet the requirements I laid out.
For TamaGo, it seems to allow developers run their application, not build an OS on the hardware. But I have not played with it, you are right.
> TamaGo is a framework that enables compilation and execution of unencumbered Go applications on bare metal
The environment does not seem to allow building a generic operating system [1]. F-Secure ported the runtime itself to boot natively. But please correct me.
> There is no thread support
The environment you run in is specifically curated for Go applications, such as the memory layout. I'd call this an "appliance" rather than enabling Go to be used for full-fledged generic operating system implementations.
Operating systems are written in other languages, such as C++ and Rust.
One requirement is that a language must be compiled and thus cannot rely on a runtime. That excludes Go and Java.
The language needs to support direct memory manipulation.
The compiled binary cannot be emitting system calls since that binary IS the kernel. Thus the compiler must be told to not link or include standard libraries.
You need to disable certain optimizations like advanced vectorization extensions and red zone use on the stack.
There are others. Lots of specific control needed.