You'll find that you are indeed correct and that it is the point of the article that neither C nor assembly are compelling low level programing languages.
But by that definition, programming in binary isn't low level either! If by the definition, there is no low level programming possible, then it's not a very useful definition.
(I mean, the point that "it's higher level than you think" might be a reasonable one to make. But arguing about the definition of "low level" may not be the best way to make that point.)
I agree with your take, but I still find the article really informative regarding the relative high-levelness of x86 instructions and as someone else wrote: “while js, java, etc. developers learned that the programming model used by the language is quite distinct from the CPU’s one, C programmers like to live in their fantasy land where they just have a very fast PDP-11” (I may have combined a few sentences from the thread, but the point is the same)
By the way: what’s your take on VLIW architectures? Possibly with the currently hardware level optimizations moved to software?
So I think we could say that 1) C is low level, and 2) the distance between C and what's really going on is much larger than it used to be, partly because the distance between assembly opcodes and what's really going on is much larger than it used to be.
Re VLIW architectures: I don't know enough to have a take about them specifically. But I fear moving the optimizations from hardware to software, because it's going to be really hard to optimize as well as Intel/AMD/Arm do, and it's going to be really easy to mess something up. (I don't write assembly if I can help it - I let the compiler writer do it. I don't manage memory if I don't need to. And so on.)
I can see some people might benefit from this, but I suspect that it's bleeding-edge people only. Most of us won't gain from going this route.
