Armchair preaching? Who is this "we" in "we are to do anything"? Unless you're contributing to a replacement, your proclamation simply doesn't matter.

> we are to start phasing out C and write modern OSes in safe languages.

Linus Torvolds probably has the best answer to why not.

https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...

"When I read C, I know what the assembly language will look like."

Except in this day and age reading the assembly language doesn't give you the same kind of insight into how the hardware will perform as it did 15 years ago.

Oh, it might still give the same insight -- for example, when people reading assembler today are the same ones who did that 15 years ago.

Or in BSD's case, 30 or 40 years ago.

Only at optimization level 0 and assuming a dumb C compiler.

And you're compiling to a specific architecture.

Go and haskell are targeted at a different level of abstraction than an OS lives at.I don't know much about crystall but I has a GC.

When it's time to speak directly to hardware, Rust and Haskell aren't exactly silver bullets: so much of the state ends up being in the chips instead of the program--thus outside the compiler's scope.

If we want to get away from C-level twiddling, we will also need to get away from C-level hardware.

It's not outside the compiler's scope at all. See for example http://www.clash-lang.org/.

How does an HDL address the limitation of software compilers at the software-hardware boundary?

By scope, I mean that the compiler can really only see as far as the source code it is compiling. In something like an OS--especially a non-microkernel--an awful lot ends up having to be read and written across the boundary, and in an unsafe context.

Oh I see. You were talking about a compiler for software talking to hardware. Well, I don't see why talking to hardware is any different to talking to a CPU or main memory or a disk.

Not so much "talking" as directly reading/writing memory outside of your source scope that is also mutated by other chips--like a DMA buffer.

Or for a traditional kernel, reading/writing directly into the address space of a user process. Wouldn't have to worry so much about race conditions there since the process could be suspended, but there is still an opportunity to fudge the indexing.

It looks like something that just gets complied to VHDL and friends? Is there some way to make the description available to user code/GHC? Now that would be interesting.