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).
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.
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.
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
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.
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.
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.
12 comments
[ 1.8 ms ] story [ 47.6 ms ] threadI 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).
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 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