[HN Gopher] Leveraging Elixir's hot code loading capabilities to...
___________________________________________________________________
Leveraging Elixir's hot code loading capabilities to modularize a
monolithic app
Author : ronxjansen
Score : 111 points
Date : 2025-07-08 07:14 UTC (4 days ago)
(HTM) web link (lucassifoni.info)
(TXT) w3m dump (lucassifoni.info)
| chantepierre wrote:
| Author 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).
| ralphc wrote:
| Why Vue over the other JS frameworks?
| ipnon wrote:
| Elixir is the best general purpose programming language for
| distributed systems.
| isodev wrote:
| It's also the best ecosystem for indie/small team development.
| With a handful of well-established libraries, one can go a long
| way without having to reach for separate/dedicated
| queue/messaging systems, job or workflow orchestrations, even
| spinning up an ephemeral machine just to run heavy workloads is
| not complex. Frameworks like Ash make an entire category of
| server applications a matter of a few declarative modules.
| pclowes wrote:
| What makes you say that? Honestly asking.
|
| I know a team using it to replace ancient massive mainframe
| based systems with modern distributed systems and the gist is
| that the language is fine, but mostly ideal for use cases that
| leverage the ErlangVM or BEAM stack.
|
| The downside they run into is the ecosystem isnt there, at
| least a couple guys wish they had just used Kotlin/Java for
| library interoperability with so much existing code already
| built and battle tested for specific purposes.
| darkmarmot wrote:
| I think that's a good point. Our largest pain point with
| Elixir is definitely the size of the community and the
| associated dearth of niche libraries. The technology behind
| it, though, is solid enough that once those libraries exist,
| things really take off. My team wrote several open source
| medical libraries for Elixir and we've seen it really expand
| into the healthcare market.
| ralphc wrote:
| I'd like to have a look at those, have a github link?
| fud101 wrote:
| I thought elixir devs have cooled on the whole hot reload update
| or is this different?
| conradfr wrote:
| That seems more about loading dynamic code.
| elitepleb wrote:
| 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
| diggan wrote:
| > 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?
| elitepleb wrote:
| 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
| toast0 wrote:
| I've used utility functions in Erlang where I make changes,
| then compile and load all modified modules...
|
| It's absolutely hot loading, there's persistent state, any
| fully qualified function calls run in the newest module.
| The gen_server pattern always calls into your behavior
| module with fully qualified calls, so those are pretty easy
| to get into new code at a reasonable time. If you write
| your own service loop, it's pretty common to call
| ?MODULE:loop() to enable hotloading there too.
|
| There's footguns; hotloading is a way to make rapid changes
| to your system, but sometimes rapid changes isn't what's
| needed and sometimes the rapid change you make is to go
| from a partially broken system to a fully broken system.
| But, there's a virtuous circle when you can make production
| changes quickly, because you can make a small change and
| observe and make many follow ups in a single day. With push
| processes that take a long time, you end up encouraged to
| make a bigger change one time, otherwise you spend all day
| waiting for traffic to move between old and new versions,
| or waiting for instances to deploy, etc.
| throwawaymaths wrote:
| no, for example if you are running a liveview in dev and
| recompiling your code the liveview does not lose its state
| and jumps into the new module, unless I'm mistaken.
| thibaut_barrere wrote:
| 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
| chantepierre wrote:
| 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.
| ethan_smith wrote:
| Hot code reloading for development (recompile-on-save) has
| issues, but production hot code loading for zero-downtime
| deployments is still a core BEAM strength and what this article
| focuses on.
| darkmarmot wrote:
| We run a large distributed cluster (currently 4 DCs spanning
| the US) and use hot code reload for live patches when needed
| and rolling deployments for our standard releases.
___________________________________________________________________
(page generated 2025-07-12 23:01 UTC)