[bjourne]

I only skimmed the video, but I couldn't see him describing it doing type reloading. Perhaps that is what he is planning on implementing. It is very hard to implement (especially if you can't control the compiler) but very useful for general code reloading. Of course everything is relative, and even if I think it is "very hard" it might be a weekend project for someone else. Generally though, code reloading is one of the hardest things to implement in a vm.

The holy grail of code reloading is to upgrade the code of a HTTP server while it is running and without disturbing any requests being processed. Very few languages except for Erlang are able to do that correctly. Some languages claim to support that, but when you experiment with them you discover "quirks" making it impossible in practice.

[jerf]

If you put your mind to it just a bit (i.e., I wouldn't call this "automatic" exactly but it's not too hard to use the support the language, runtime, and libraries have), Erlang can even do a harder thing, which is update the code handling a given socket connection or something live, in a principled manner, while never dropping the connection.

Since HTTP is transient, it's actually a bit easier than a raw socket since you can expect it to go away soon, or even in the case of HTTP2, you can often expect to just close a socket as long as it's not currently active and get away with it. Many languages can smoothly upgrade an HTTP server by handing off a listening socket to a new process with new code. But even that won't save you for live sockets, because even if you hand off the socket, you haven't got a clean mechanism for handing off its accompanying state.

Several interpreted languages can sort of do this, but I'd call it in an "unprincipled" manner by just slamming new code in place and hoping for the best. Erlang explicitly upgrades the gen_* instances and you can provide a function for converting the old state to the new state cleanly.

[bjourne]

> Erlang can even do a harder thing, which is update the code handling a given socket connection or something live, in a principled manner, while never dropping the connection.

That's what I meant. :) Hot reloading when nothing is "in flight" isn't so hard. The Erlang the Movie example, hot-fixing a PBX without disturbing phone calls in progress (real time requirements!), is really hard.

[jerf]

Ah, my apologies, because when you said "The holy grail of code reloading is to upgrade the code of a HTTP server while it is running and without disturbing any requests being processed." I thought you were referring to the ability of the BEAM VM to also have multiple versions of the same gen_* running, so that old requests can still be running on the original code while the new requests come in on the new code. This is in contrast to the things that came to mind like Python, which technically can replace a function reference live, but there's no such ability to partition who's in the old vs. new space like that, so it's too dangerous to be practically used (or at least not without a lot more supporting code).

BEAM's really got it all on this front.

[drb91]

> Erlang can even do a harder thing, which is update the code handling a given socket connection or something live, in a principled manner, while never dropping the connection.

I imagine that runtime type errors is what makes this possible.

[MuffinFlavored]

> The holy grail of code reloading is to upgrade the code of a HTTP server while it is running and without disturbing any requests being processed. Very few languages except for Erlang are able to do that correctly. Some languages claim to support that, but when you experiment with them you discover "quirks" making it impossible in practice.

You can kind of do it with node.js, but man do things get ugly fast when you manage state/connections in modules on reload.

[muddybytes]

in the olden days there was a “copyover” patch for a MUD codebase that allowed hot reloading with hundreds of active sockets in a single threaded app.

[KallDrexx]

He talks about it at the 27 minute area