C may not meet the authors definition of low level, but is still far lower level than most viable alternatives.

Short answer: No, this guy is all the way up his own rear end.

Longer answer:

Author: "C is not 'close to hardware'"

Also Author: "Successful one to one struct comparisons may require padding, which isn't automatically applied!!!!!"

Like if you have an entire PhD on this stuff and you don't understand how and why you need to pad, when you need to do it, and how to calculate the proper amount of padding, maybe somebody should've stopped you before you showed your whole ass on the Internet like that.

(Padding is applied to align chunks of data more closely to the size of memory writes possible in a given architecture, it is extremely system dependent and you use it in very specific circumstances that you, a beginner, do not need to understand right now other than to say that if the senior says thou shalt not fuck with my struct you better not)

I see the argument that C on an Intel CPU is not low level enough for this person. On arm cortex m and r series CPUs, it's low enough. (I don't know enough about the A series to say this).

The gripe is mostly that there's microcode in the pipeline for branch predictions and that takes the control away from them. If you want to own that control, You're going to lose on speed.

Should you be bothered? Generally, No. If you are, there are CPU options out there with smaller pipelines and much less predictions going on. But don't expect them to compete in the same arena as an application class CPU. (Intel, AMD, Arm A series likely)

The C compiler or third party libraries can provide support for parallel execution and SIMD. That article is just used by people in an attempt to argue that C's strength in being a good low level abstraction is false, which it isn't. C is the best portable abstraction over a generic CPU that I know of. If you start adding parallel features and SIMD like the article suggest, you'll end up with something that's not a portable low level abstraction. To be portable those featues would have to be implemented in slow fake variants for platforms that doesn't support it. We can always argue where to draw the line, but I think C nailed it pretty good on what to include in the language and what to leave up to extensions and libaries.

C is not a perfect abstraction, because it is portable. Non portable features for specific architectures are accessed through libraries or compiler extensions and many compilers even include memory safe features. It's a big advantage though to know Assembly for your target platform when developing in C, such that you become aware fx. that x86 actually detects integer overflow and sets an overflow flag, even though that's not directly accessible from C. Compilers often implement extensions for such features, but you can yourself extend C with small functions for architecture specific features using Assembly.