I was recently doing some language evaluation for rewriting an existing system in Go to improve its cross-platform compatibility. One of the things I realized in this exercise was that "compiles to C" was a powerful feature - not because of C itself, since C often gets in the way of the source language's intent - but because it means that the result fits into and leverages all the C-based tooling, facilitating the desired level of platform independence.
And for a lot of projects today, "the bottom" ends with C for precisely this reason - while the fact that C is the chosen language for this task is completely arbitrary, as arbitrary as the status quo hardware paradigm of "x86 on desktops, ARM on mobile". I could imagine a universe where it was an extended form of Basic or Pascal that ruled the world instead.
Likewise, I was also looking into extending Lua with a small DSL interpreter that could accelerate certain byte-level tasks: copy around blocks of bytes, run some common algorithms quickly, define spaces for variables, apply some parameters. At first I thought of this language as a "VLIW" assembly language with a particular focus on having a big bag of tricks, but when I compared my semantics with actual hardware assemblers, I found that having no registers or stack manipulation and focusing only on direct memory addresses changed the character of it so much as to make it a different beast, one more like the "autocoders" of the 1950's: not quite ALGOL, and yet clearly headed in that direction.
All of which is to say - the more you are comfortable with compilers, the more the bottom just becomes the thing you happen to be leveraging to ship product. It isn't "the real stuff" until it becomes the specification language. Some things, like how numeric types are defined in hardware, force the terms of specification way up the stack so that the hardware may be used at its capacity. But that in itself is an "essential complexity" in computing, where the physical realities coincide with the desired programming model. When it's software defining the spec, as in our libc-and-Javascript-driven universe, that's more akin to social complexity, but it produces the same kinds of effects.
And for a lot of projects today, "the bottom" ends with C for precisely this reason - while the fact that C is the chosen language for this task is completely arbitrary, as arbitrary as the status quo hardware paradigm of "x86 on desktops, ARM on mobile". I could imagine a universe where it was an extended form of Basic or Pascal that ruled the world instead.
Likewise, I was also looking into extending Lua with a small DSL interpreter that could accelerate certain byte-level tasks: copy around blocks of bytes, run some common algorithms quickly, define spaces for variables, apply some parameters. At first I thought of this language as a "VLIW" assembly language with a particular focus on having a big bag of tricks, but when I compared my semantics with actual hardware assemblers, I found that having no registers or stack manipulation and focusing only on direct memory addresses changed the character of it so much as to make it a different beast, one more like the "autocoders" of the 1950's: not quite ALGOL, and yet clearly headed in that direction.
All of which is to say - the more you are comfortable with compilers, the more the bottom just becomes the thing you happen to be leveraging to ship product. It isn't "the real stuff" until it becomes the specification language. Some things, like how numeric types are defined in hardware, force the terms of specification way up the stack so that the hardware may be used at its capacity. But that in itself is an "essential complexity" in computing, where the physical realities coincide with the desired programming model. When it's software defining the spec, as in our libc-and-Javascript-driven universe, that's more akin to social complexity, but it produces the same kinds of effects.