Lisp has had this features since day 1. But Lisp-like langs like Clojure, Racket, etc. don't have it. This is one of the fundamental features of Common Lisp and I don't know why most other Lisp-wanna-be's don't implement it.
Clojure has it for a large percentage of functionality: things like https://github.com/clojure-emacs/cider depend on it. However, this mostly stays in dev-time and isn't used much for releases. Which I find a bit funny because Clojure's functional, data-driven philosophy is great for enabling painless hot-code updates
I don’t understand the particulars, but one selling point of biff is it’s got built-in support for updating things directly in prod via the REPL.
There’s a fun interview with the biff guy on the podcast “the REPL”. He talks about how much fun it is to develop directly on the prod server, and how horrified people are by it lol.
Came here to say this. In Lisp, you can just compile a function, or load a file and it just works. It's not even sold as a hot feature, not the way Erlang sells it. It's just a feature.
I manage a few websites written in Lisp, and updating them is as simple as push code, recompile and it works.
But what if the system is running and the new function takes different arguments or something? What if there is data loaded in the system, what happens to it?
Simply loading new code is easy, ensuring the whole system works seems to require a bit more effort.
Common Lisp has a bunch of features designed to enable migrating the system. e.g. update-instance-for-redefined-class ( https://www.lispworks.com/documentation/HyperSpec/Body/f_upd... ) lets you write code to update instance data between class versions when a class definition is reloaded.
It turns out, though, that making hot-code reloading work well is mainly a question of how you design your system: designing for hot code reloading isn't all that hard for 90% of cases once you figure out the relevant techniques.
We do this in q/kdb+ systems often for patches. An important thing about these languages is that this kind of workflow is part of the core for solving problems. So when you are building a system one of the aspects of its design will always allow for this update method. Then when you push a patch you both know the impact of the change (because you've tested the exact same steps in a dev/QA/UAT/Beta environment) and the work required to do it safely.
Major releases do go through a full shutdown and release cycle though.
Those sites have something like Phoenix LiveView or it's something ad hoc like a simple SSR template engine? Would be nice to have something to handle migrations in the client side code to match the server side API.
