I really want to play with HaLVM at some point. Unikernels are fascinating to me. Think of how many server hours we can save by just booting up a unikernel on each incoming request.
The problem with HTTP, for me, is that I need to have some program running, listening on a port, in order to access the functionality that I've chosen to expose behind a REST API.
With unikernels, RESTful web servers go from being a special kind of function, that requires an always-running executable, to the executable being "applied to" incoming requests, as needed. So a DNS server can basically take an incoming request, boot up a unikernel in 20 ms, reply with the unikernel IP, and the newly started unikernel will receive the actual request data shortly thereafter. This feels more like "applying a web function" to an incoming request, and throwing away that function when the connection is closed - like a garbage collector, of sorts. Rather than having some executable sit and wait for data on a TCP socket, it would be nicer to be able to distribute web apps as shared objects: loaded into memory when needed and applied to a request.
This actually sounds like how you would do this in Erlang - and it's really elegant because WebSockets/Server-Sent Events are simply encapsulated in processes spawned when the request is received. I don't know if this is how Erlang webservers actually work, but this is how I'd do it.
you might be interested in http://erlangonxen.org/ (LING) if you haven't seen it already!
One of the contributors recently wrote: maximk commented on 25 May "All recent updates to the code were customer-driven. New users mean new updates. The likely application area for this is NFV, modular software for telecoms. No definite plans"