> People writing real kernels or embedded code have to write little shims in platform-specific assembly code to hook their C code up to the hardware
Platform-specific extensions to C, but not assembly. IIRC declaring a register on the hitech picc18 compiler was a cast of an address to a specific type, and on another compiler was a pragma. But that happens in compiler-supplied include files, so the C programmer ends up with a PORTA macro. Point being, the algorithmic code written in C isn't entirely beholden to a specific implementation and what platforms it chooses to support.
> C has a fundamental principle: you only pay for what you use
Unfortunately, there is a lot you are unable to use even when you are more than willing to pay. I'm basically proposing augmenting C with modern statically analyzable language features, so that one is able to pay for more capabilities.
The problem with the current bunches of languages is their extreme lack of maturity. Rust currently looks the most promising to me, but I can't be sure that at version 0.4 the main contributors won't move on to other things, leaving its popularity to be eclipsed by Deca 1.0. A working application can always be recompiled with a frozen version of the compiler, but if your goal is to write a major library that exports its abstractions as more than a C FFI, language community is a major concern.
Platform-specific extensions to C, but not assembly. IIRC declaring a register on the hitech picc18 compiler was a cast of an address to a specific type, and on another compiler was a pragma. But that happens in compiler-supplied include files, so the C programmer ends up with a PORTA macro. Point being, the algorithmic code written in C isn't entirely beholden to a specific implementation and what platforms it chooses to support.
> C has a fundamental principle: you only pay for what you use
Unfortunately, there is a lot you are unable to use even when you are more than willing to pay. I'm basically proposing augmenting C with modern statically analyzable language features, so that one is able to pay for more capabilities.
The problem with the current bunches of languages is their extreme lack of maturity. Rust currently looks the most promising to me, but I can't be sure that at version 0.4 the main contributors won't move on to other things, leaving its popularity to be eclipsed by Deca 1.0. A working application can always be recompiled with a frozen version of the compiler, but if your goal is to write a major library that exports its abstractions as more than a C FFI, language community is a major concern.