Microsoft has done some very interesting research in this direction, if you look into Singularity:

http://research.microsoft.com/en-us/projects/singularity/

Also, Mothy Roscoe et al have been working on Barrelfish which uses the Eclipse constraint programming language as an OS service to sort out all kinds of OS management and resource allocation problems:

http://www.barrelfish.org/

A lot depends on where you put the division between low-level and high-level languages. For example, different people tend to put a language like C++ on different sides of that divide.

Regarding your questions:

1. I don’t believe there is such a difference between low-level and high-level languages, but more a difference between interpreted languages and languages that compile to native instructions.

   But there might also be a difference in culture between programmers, where the once that use a low level language focus more on the performance aspects of the (design) choices they make.

2. If you consider C++ to be high-level, then there is at least one OS written entirely in a high-level language (Symbian OS is written in C++). What stops you from writing an OS in most high-level languages are two things:

   • An OS needs low-level access to memory and hardware and perform dirty tricks on them. This kind of access is generally considered unsafe for application-level programs, so many high-level languages don’t allow it.
   • An OS needs to execute without support software being present, such as interpreters. This makes it extremely hard to write an OS in a language that can’t easily be compiled into native instructions.

There are a number of good reasons for this.

Today’s low-level language was yesterday’s high-level language

Yes, believe it or not, once upon a time even C was viewed as a high-level language. Even ~20 years ago it was common enough to see it described as a “mid-level” language. This was a time before OO was as popular as it is today, Java didn’t exist, C# didn’t exist, even C++ wasn’t properly standardized yet.

Historical Inertia

Operating systems that you use today have deep deep roots in history. Windows goes back to the early/mid 80s, Unix goes back to the early/mid 70s. There is a LOT of old, working code in operating systems, and you generally don’t want to rewrite old, working code.

At some point you have to go down to the hardware

This happens in the kernel, it happens in drivers, it happens in memory management subsystems, it happens in the filesystem. Sure you can layer a high-level language on top of it, but you still need the ability to more directly access the hardware that a lower-level language offers.

Portability

I don’t mean portability to different hardware or a different OS as it’s more commonly understood today; this is more subtle. There is one major advantage of providing a C-based interface for something, and that is the fact that virtually every other language that exists can link to C. Even the Windows API is still a C-based API these days for that reason.

Personal Preference

Some people just prefer to program this way, and that can be a major factor. For example, Linus Torvalds has a famous rant against C++ which makes it pretty clear that as far as he’s concerned, C will always be his tool of choice for this kind of work (the content of the rant and whether or not you agree with it is irrelevant to this discussion; the fact that the rant exists is enough).

Taken together, these should clearly establish why an operating system was originally written in something like C back in the old days, and why very significant chunks of it – even today – remain so.

First, there are some bootstrap issues. Most of the features that make high level languages easier are based on abstractions that a kernel must provide itself. How do you write a memory manager in a language that requires a memory manager? How do you write I/O drivers without using the nice I/O standard libraries of your language? How do you create threading and synchronization primitives without using the language’s libraries?

Second, it’s extremely useful and much more readable when writing operating systems to be able to assign a variable to a specific memory location. This is easy in C, and every single C programmer knows how to do it. If it’s even possible in higher level languages, it’s so rare that only gurus know how to do it.

In other words, when you account for all the limitations and modifications you would have to accept, C and C++ start looking a lot easier.

A main reason for the dominance of C for operating systems lies in history – current mainstream operating systems like Windows and all forms of Unix (BSD, Solaris, HP-UX, MacOS X, … as well as clones like Linux) go back a long time, before OO and other “high level” constructs became mainstream.

For the core of the operating system besides performance there are needs to e very specific about the hardware instructions and one needs full control over memory which languages like C do very well.

For embedded systems there sometimes are operating systems using higher level languages for greater parts of the system. One notable example is JavaOS by Sun.

For widespread operating systems an notable example not using C also is the classic MacOS before MacOS X – that was in large parts written in a dialect of Pascal which allowed some form of object orientation.

First of all, bootstrapping requires at least a small part to be written in Assembly or equivalent.

Second, there was a OS written in an indisputably HLL – Lisp Machine.
(The fact that it failed commercially had more to do with other hardware becoming cheaper faster and the triumph of Worse is Better than with deficiencies of its philosophy or design).

Third, C++ is quite object-oriented and high level, so, as others pointed out, Symbian OS is another example.

Fourth, there is little need for new OSes at this time. We already have quite a few linux and bsd flavors which run on just about any hardware, and creating a brand new OS from scratch is quite expensive.

To better phase what I wrote previously.

The Burroughs 5xxx – 6xxx machines did not have an assembly language. The lowest language available was an extension to Algol. The Algol was implemented in hardware. The OS and all languages were written in Algol. It outperformed all the competitor machines of the time. It also required significantly less code which made it much easier to maintain. It had stack hardware which supported a recursive language such a Algol.

The Burroughs operating system evolved into a version called MCP. MCP currently runs on Unisys systems.

Most of the higher-level languages that you mention have a feature that doesn’t fit well with operating systems: Automatic memory management. You can’t rely on a garbage collector when writing a real-time system — either soft (which is what an operating system is) or even worst hard. To quote Tanenbaum [i]:

Some things that C does not have include built-in strings, threads, packages, classes, objects, type safety, and garbage collection. The last one is a show stopper for operating systems. All storage in C is either static or explicitly allocated and released by the programmer, usually with the library function malloc and free. It is the latter property — total programmer control over memory — along with explicit pointers that makes C attractive for writing operating systems. Operating systems are basically real-time systems to some extent, even general purpose ones. When an interrupt occurs, the operating system may have only a few microseconds to perform some action or lose critical information. Having the garbage collection kick in at an arbitrary moment is intolerable.

Now, you might argue that C++ is also a good candidate since it offers manual memory management. C++ has already been used in some operating systems such as Symbian (mentioned by Bart) and BeOS. But IMHO C is still the fastest language that can be ported in many architectures without a huge effort (in contrast to assembly of a specific architecture).

_{[i]: Modern Operating Systems 3rd edition, page 73}

As others have pointed out, several operating systems have been written in high level languages. Perhaps what you mean is that all the successful, mass market, general purpose OS have been written in some combination of assembly, C, and C++?

Most high level languages have tons of helpful features that carry an associated performance cost. Automated memory management is an obvious example, bounds checking of arrays is another. If you are writing a general purpose OS you are likely to run into situations where the performance penalty of these helpful features is more than you are willing to pay. At that point you’d like to be able to turn them off. Languages like Python, C#, and Java vary in which features you can turn off, but none of them are as versatile as C or C++ in this regard.

In this aspect C and C++ are almost as versatile as pure assembly. If you decide that you need ten different memory managers covering ten different memory allocation scenarios you can implement them all in C and C++, and load and unload them as you see fit. Heck, you don’t even have to link to the standard C runtime libraries or startup code if you don’t want to.

The real answer is Money. There’s not enough perceived benefit of a high level language OS to justify spending the resources to build one and then push it into the mainstream. There’s massive cost involved in building a new driver for each piece of hardware it needs to support, for example.

There are various OSes written in high level languages, with the primary purpose of research, such as Oberon and Singularity.