Which seems sensible; if you want to write different components in multiple languages, each component can be its own VM and they can communicate over the (virtualized) network. It's the natively-compiled, statically-linked equivalent to putting your runtimes in Docker containers.

I was thinking, earlier, that this approach could be taken even further: rather than relying on Xen, it'd be nice to extract the drivers from the Linux kernel into their own project, an exokernel library with a defined ABI. Platform runtimes like Erlang, OCaml, Haskell, etc. could each build a "complete bare-metal kernel-binary" version of themselves, simply by linking to that exokernel library.

(And Linux could obviously move over to consuming the exokernel library itself. I guess a POSIX environment would technically just be the "complete bare-metal C kernel-binary.")

> if you want to write different components in multiple languages, each component can be its own VM and they can communicate over the (virtualized) network

Those "components" and "virtualized network" really resemble "processes" and "IPC" to me. Except that in MirageOS/Foo-on-Xen/etc each process has its own device drivers. And, indeed, those beg either for putting into a sort of shared component.

But... aren't we almost reinventing microkernels here? With the only distinction of using shared libraries instead of server processes?

Yes, we are. I wouldn't say re-inventing, though. Hypervisors are effectively an optimization of microkernels: modern ISAs (e.g. x86-64) have special instructions to make "hypercalls" faster than plain-old context switches, so any modern implementation of a microkernel would be forced by practicality to act as a hypervisor.

Though, there's another advantage that comes specifically from thinking of each process as a separate "machine": each process gets to participate fully as an Internet peer, with its own unique, public-routable IPv6 address.

You can extract the drivers from the NetBSD kernel into exactly that, its called rump kernel http://www.rumpkernel.org and it can run on Xen among other places see https://github.com/rumpkernel/rumpuser-xen or just in userspace under Linux say - it is getting easier to run any application on it, there is still a bit more work needed (thread support is not there yet). Working on it though, and it should get easier to build and run application code over the next few months.

One advantage of using a BSD rather than Linux is licensing, as linking Linux kernel code into your application will probably force you to release as GPL. NetBSD also has an initial portability advantage, as you could always cross compile it.