The Continuing Relevance of C
cs.uiowa.edu
cs.uiowa.edu
C's low levelness not only gives the programmer a needed degree of precision control, but also makes the language easy to implement elsewhere. There is a version of gcc for the x86, and for the ppc, and the sparc and the arm, and to port programs between them, often all you need to do is is set the right compiler flags and use preprocessor commands wherever necessary. C is highlevel enough to keep you from having to write architecture specific code, but low level enough to allow you to do so.
For Microsoft, I read somewhere several years ago that they had no plans to support C99, because they viewed C as inconsequential compared to C++. I have not kept up with Microsoft C compiler development at all, so I don't know if this is still true or not.
A sign of the flaws in the author's argument is that C++ clearly offers just as much control over the hardware as C. However, an order of magnitude more OSes are written in C than C++. Anyone who's tried to write one in C++ knows why; trying to bend the tool chain to support bare-hardware is a daunting task.
As far as I can see, the reason why C++ has never really taken off for OS design is both historical and technical. When I was working at a major telecommunications firm, our C++ coding manual dated back to 1985--any features that weren't stable in C++ as of '85 simply could not be used in modern code in '99.
Large scale engineering shops are very, very slow to change. Right there's one major reason why C++ hasn't caught on in the OS level.
The other major reason has to do with the way C++ implements inheritance. The fragile base class problem is a killer for OS level design. If you want to dodge that, then your best bet is to write your kernel in the C subset of C++ and eschew C++'s object model.
Finally, there's the issue of portability. C++ didn't even standardize until 1998. Compilers lagged substantially behind the Standard until about 2003. Using sophisticated C++ features like the STL tended to lock you into one particular compiler vendor. That's not something an OS designer especially wants.
I know of several engineering shops that write their code in C, precisely to get around vendor quality-of-implementation issues in their C++ compilers. However, despite the fact they write their code in C, they make compiling it with a C++ compiler part of their software engineering practice, in order to take advantage of the C++'s compiler's much stronger type checking.
I have yet to see the tool chain be an issue in C++ development. That's not to say it can't be an issue or that you haven't seen it--only to say I've never seen it become a substantial issue.
Yes, but the constraints on embedded systems make this path harder. On larger systems it just doesn't happen. It would make a good question to ask Bill Joy. "Bill. Why didn't you program bsd in C instead of lisp?" ... WHACK!