It is hard to express how fundamentally wrong the author is, in his definition of abstraction overhead, and his criteria for sound implementation practice.

The term "abstraction overhead" is already defined rigorously as the difference between the runtime performance of handwritten pre-specialized code, vs code that uses a more general abstraction.

So we don't have a proper term for what the author objects to, but avoiding powerful language features -- most particularly, destructors -- would be a huge step backward.

Most of us don't get the luxury of discarding a system and rewriting from scratch. Instead, we make the code we have maintainable. Each of the tools the author reviles is present in the language specifically because using it properly makes libraries and programs more maintainable. A system coded using the features wisely, well, and pervasively is more maintainable, and fundamentally better.

The alternative would be to say that systems in raw C, or assembly language, are more maintainable, which is obvious nonsense.

The experiences that led the author to his conclusions are no doubt tragically lamentable, but do not represent anything like the mainstream experience of system construction and maintenance.

> The alternative would be to say that systems in raw C, or assembly language, are more maintainable, which is obvious nonsense.

The existence and success of Linux alone seems to contradict your opinion, and that's hardly the only pure C code base of that size that's been successfully developed and maintained over decades by many contributors. If anything, that makes C look like a pretty good choice for creating a big maintainable code base.

you cannot make useful comparisons with "Linux alone".

See for instance SerenityOS (https://github.com/SerenityOS/serenity) : in one year and a few months it went from zero to full-blown C++ OS with graphical shell, userspace, and a dozen apps (https://github.com/SerenityOS/serenity/tree/master/Applicati...)... in 140kloc.

Of course we'll never know how Linux would have turned out if it had started today with modern C and modern computing power, but it does not seem out of this world that C++ is a more productive language than C by a non-negligible amount.