Yes, many OS’s are written in C (Unix) and C++ (Windows, with C at lower levels). OS X is written in C and Objective-C, which is a different animal - better than C++, but still derived from C.
VMS was written in Bliss-32, IBM mainframe OS’s are a combination of ASM/370, PL/I and PL/S. The old minicomputer OS’s were written in their respective macro assemblers.
I’ve written code in more than a dozen languages. When I first converted to C from Pascal and FORTRAN, I thought I was really warm poop. Then I learned over the years that C, for all it’s down-n-dirty power to tweek the iron... is like keeping a loaded pistol in the same room with a child who abuses meth: Sooner or later, there WILL be some problems.
There was a wonderful little observation made by a wag in Datamation (which only the old farts here will remember) around 1984:
“C is a language for consenting adults, Pascal is a language for children and Ada is a language for hardened criminals.”
Most programmers on large projects fall into the latter class of human, especially when they have some middle-management dweeb with PERT charts trying to convince them that they can cut out much of the unit testing to meet their deadlines.
Ada-83 has/had a lot of shortcomings and wasn’t really ready for prime time. Ada-95 has cured most all of those, and the latest Ada spec cures the rest.
I’d vastly prefer to see operating systems now written in Ada. It would solve a lot of these security problems by enforcing clear thinking on the programmers’ part - rather than this idiotic “let’s just keep fixing it until it compiles” mindset that seems to have taken over the industry when the “children of the PC era” came of working age. Desk-checking of code has gone by the wayside now - when I started slinging code, you didn’t run the code on the machine for the first pass of debugging. You got a bunch of people together in a room, printed out the code on 66-line greenbar paper, then you sat down for several hours and walked through the entire unit, line by line, with people asking “What if X changes to Foo here? What happens if this input is wrong?” and so on.
Since we’re no longer going to have desk-checking and structured walkthroughs, it is time to make the tools do the enforcement of better programming practice.
With Ada, if you have not really thought through (all the way) how your interfaces work, how your data flows from type to type through the program - it won’t compile, much less link. A typical early Ada programmer has this reaction:
“Dammit, my code has been ‘finished’ for a week, but it STILL won’t compile! Damn this stupid language... in C, I’d be done by now!”
Then the kid finally gets it to compile by fixing all the type usage errors, interface errors, exception handling, etc. He finally gets it to compile... and then he links it.
And he finds out in unit testing that it just seems to work. Very few runtime errors are found... fancy that.
Overall, the manager would find (if they’d take the chance) that they spend less time overall getting the project’s goal met if they find the errors as early as possible. The later in the development lifecycle that an error is detected, the more expensive it becomes - by several orders of magnitude. This is nothing new to anyone who has read “The Mythical Man Month” or other tomes of that era, but today kids are too busy spouting nonsense about this, that or some other programming language vs. another, and not spending enough time thinking about the big issues in software development - like making sure the code matches the specifications, interface design, etc.
NOOO!!!!! Not Ada again. I remember the government trying to force that down everyone’s throat. Yes it has some good points (that you point out), but it needs user community acceptance to be a viable solution. It was just too much a red-headed step child that the big government was trying to shove down programmers throats. If it had a different backer it may have been more successful.