Leveraging Elixir's hot code loading capabilities to modularize a monolithic app
lucassifoni.info
lucassifoni.info
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).
What I'm truly rooting for is a non-limited Elm.
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.
for HL7: https://hexdocs.pm/elixir_hl7/main.html
for MLLP: https://hexdocs.pm/mllp/readme.html
Elixir is not perfect, but for me working alone dependency hell was the bottleneck with Python. Now the bottleneck is adding features, which is right where it should be.
For the less common ones, we tend to just roll our own which in most cases isn't that bad if you have reference implementations.
I think the most under-appreciated aspect of Elixir is how it helps reduce complexity. And there isn't a silver bullet here, but the tooling, immutability, pattern matching, process-based concurrency model, etc are all design decisions that, IMHO lead to simpler, more robust code.
(Caveat: of course, like any language, you can make a mess of things.)
I'm curious what libraries they wish existed.
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?
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.
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
Most host have blue-green deploy options which reduce downtime and there are fewer corner cases to deal with.
I find local recompile very useful for prototyping in development mode. So much so that I have a keyboard shortcut to trigger a recompile. (I don't like recompile on save.)
A multi-DC running cluster where parts are progressively swapped at runtime. No database, only OTP.