Comment by jacquesm

> The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages?

The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.

> On a different note: why should the kernel even handle IPC or scheduling?

Because any other solution will quickly run into chicken-and-the-egg style problems.

> Those take the basic capabilities of context switching, timer management, and memory management.

Yes. But only one timer, the rest should be free to use by other applications.

> Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server?

No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.

> Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction.

Indeed. And they do.

> Everything else either follows from the hardware or is left to the whims of software.

A lot of the stuff that 'follows from the hardware' can be dealt with at the application level.