The framework here is fairly general and you should be able to run other code directly under Xen eg Python. Node would be harder as there is no threading which libuv needs.

There is threading in the underlying framework. In fact, since there is no VM support, threading is all you have.

However, there is no pthread support which is probably what you are referring to. I don't think pthread support would be difficult to add. Most likely it's trivial in case non-preemptive run-to-block threads are ok. If someone has a use case for pthreads, I'm up for a discussion.

Libuv which node.js uses has threads to do non blocking file IO. Haven't looked at the code for ages though so not sure exactly what it needs.

Is this because asynchronous I/O calls don't work consistently well on all the platforms that libuv targets?

Async file IO on Linux is a bit odd, although it is gradually getting better. It only applies to unbuffered IO (I think still). So you have to use a thread to read or write. Windows has a more usable version. There is a Unix standard API but it is just implemented with threads normally anyway.

OCaml on Xen http://www.openmirage.org/

What advantage is there to running something like this on Xen rather than running an almost equally self-contained process on a general-purpose OS kernel like Linux or BSD? Is Xen's resource isolation that much better?

Perhaps not, but I think the purpose of these Xen exokernels is to run on IaaS platforms which provide Xen VPS, like EC2 or Linode.

The limitations seem pretty high. Why would I use this when I could run something like Docker on bare metal?

Docker is a way of making config management easy. Here there really is less stuff. You build a binary with your whole application and all its dependencies that actually self hosts. And is smaller than Docker's init process.

And a VM is better isolated than a Linux container.

EDIT: the restrictions are not necessarily permanent either. Its only a first early release...

Yes, tiny resource overhead while still providing near-complete isolation is a big benefit. The current memory overhead from using file system drivers and TCP/IP networking is around 8MB, and I'm sure there's a bunch of fat in there that could be trimmed off.

It's going to be interesting to see where the exact set of supported application images converges as use cases arise. For example, I'm pretty sure fork() will never be supported -- would it fork the VM? -- but some of the other things are up for discussion.