Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
1–10 of 27 posts
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#2Author here, thanks for sharing ! Happy to answer any questions.
I think the article outlines it, but I'm at very low scale, with custom development for every client. I mostly build mini-figmas, collaborative or not, that automate specific document pipelines on top of my software, backed by elixir+liveview (or elixir+vue+channels).
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#3Elixir is the best general purpose programming language for distributed systems.
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#4I thought elixir devs have cooled on the whole hot reload update or is this different?
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#5I thought elixir devs have cooled on the whole hot reload update or is this different?
That seems more about loading dynamic code.
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#6I thought elixir devs have cooled on the whole hot reload update or is this different?
Elixir removed a jankier https://www.erlang.org/doc/apps/sasl/appup.html mechanism that defined how state is upgraded or downgraded, while watching a directory and recompiling a module automatically or manually from the repl is still common
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#7I thought elixir devs have cooled on the whole hot reload update or is this different?
Elixir removed a jankier https://www.erlang.org/doc/apps/sasl/appup.html mechanism that defined how state is upgraded or downgraded, while watching a directory and recompiling a module automatically or manually from the repl is still common
> while watching a directory and recompiling a module automatically or manually from the repl is still common
That makes it sound like the "hot" part has been removed then, and it's just basically a "live reload" rather than "hot code loading", is that right? There is no persistent state and you get a fresh one after the automatic compilation happened?
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#8Earlier quoted context omitted.
Elixir removed a jankier https://www.erlang.org/doc/apps/sasl/appup.html mechanism that defined how state is upgraded or downgraded, while watching a directory and recompiling a module automatically or manually from the repl is still common
> while watching a directory and recompiling a module automatically or manually from the repl is still common That makes it sound like the "hot" part has been removed then, and it's just basically a "live reload" rather than "hot code loading", is that right? There is no persistent state and you get a fresh one after the automatic compilation happened?
queued messages stay around in the mailboxes, so no state is lost, but don't get migrated/transformed/versioned via the appup mechanism, unless you opt back into it via libraries for it like https://github.com/ausimian/castle
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#9I thought elixir devs have cooled on the whole hot reload update or is this different?
Overall, it's not widely used nor pushed (blue green deployments are now very common), but it still has interesting uses.
For instance, very high availability without blue-green (using a front-end that can be hot-patched), or... musical endeavors (such as live reloading code that generates music, on the go) https://youtu.be/_VgcUatTilU?si=DDfe4FN3Nw9OzRhF&t=122
Re: Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
#10I thought elixir devs have cooled on the whole hot reload update or is this different?
I'm not using this to update the app itself - which is a docker container that gets updated when I push a new version. I'm simply using the BEAM's code loading capabilities to add client-specific parts to the app while it is running. They are part of the monorepo (and thus part of the app at dev time), but get stripped at build-time so they can be selectively loaded later.