I think releases.exs has not moved the state of the art forward from what we already had with Distillery, but I am quite looking forward to runtime.exs when Elixir 1.11 ships in ~October. That will really drive the conversation forward and introduce the required learnings earlier in a project’s lifetime, which is all to the good. The version of releases introduced natively with Elixir 1.9 does a minimal subset of what Distillery provides, and some of the things that were omitted are things I still want for every project today. To be honest, I think most people switched to native releases not because Distillery’s documentation was hard or its features were overwrought, but because it has every appearance of being unmaintained. I hope that’s not true, but there’s been relatively little communication around it since Paul mostly left the Elixir ecosystem. I’m grateful to his incredible work on Distillery and libcluster, but it feels like we’re on shaky ground where the new solution is incomplete and the incumbent is stagnating.
Hot code upgrades have no analogue in other languages, and edeliver is basically a Capistrano clone, which in hindsight requires a sliver of Ansible to reimplement if you enjoy that deployment model. I emphatically don’t. These tools and techniques cannot be adapted to a second or third language at a polyglot organization, or at least I feel attempting to do so is not a good use of time. If you are at an org that allows that fluidity of language use, you have to optimize your deployment practices for the lowest common denominator and start communicating and working with a standardized process and vocabulary around deploys. There’s no space for bespoke single-language stuff, given my belief that hot upgrades are not actually necessary for delivering business value in most products/orgs.
I don’t have the goal of arriving at something that is like-for-like with the BEAM. If I valued all of its designs and principles that highly, I would stick with Elixir and be happy. I value languages that let me do meaningful work, do it well and comfortably, and avoid needing superfluous hardware to power it. I value code that is resilient to human and technical failure. The BEAM does not have a monopoly on those properties.
I think most of the rest of your post is actually supporting my own stance, highlighting that I value things and want to pursue areas of work that are implicitly or explicitly non-goals for Elixir. It’s okay for those things to be non-goals for Elixir, but it’s also okay for me to recognize that disconnect, and that the values driving the design decisions are not my own. That means I probably have to look elsewhere to avoid suffocating as a developer.
Totally happy with your points and your tone, thought it was all in the spirit of respectful challenge and I appreciate that. Lots of great links, too.
