Ahh, I wonder if this is what I remember! R10 does sound about the right time period!
I still don’t see the point personally, extract and run is pretty trivial enough and you almost always have other assets anyway that are packaged adjacent so you need to pack it up anyway, so yeah, I don’t see the point.
And Docker makes it even less relevant…
It’s a convenience, but only for pretty limited use cases, in my opinion.
This seems like an appropriate time to post this, from a recent comment on HN:
We [at Discord] have one (very low throughput) service that runs Elixir inside of a docker container, however, the rest just run BEAM on the VM directly, with no containerization. BEAM at higher load does not enjoy sharing cores with anyone. Most of our Elixir services sit at 80-100% of CPU on all cores. BEAM likes to spin for work, and is CPU topology aware. Two BEAM scheduler threads running on the same core is a recipe for disaster. Since we’re fully utilizing our VMs, and shipping the tars is simple enough, Docker gave us too much operational overhead for it to be worth it.
From that same comment
Aside from deploying go binaries, Elixir binaries have been the next easiest thing.
Very interesting to hear from a large company using Elixir extensively (especially in regards to this thread). In my mind it would be great to improve the “binary” distribution model, event if it isn’t always used extensively. I believe that simple binary distribution can be a very simple easy-to-use method for developers just getting started, and the largest benefit is that it is very easy for them to understand. It is okay (IMO) if it isn’t the most performant.
I’ve certainly put Elixir into production on bare VMs, and it’s just not that hard. (Although still room for improvement…)
My point about Docker is not that it’s the best way to deploy Elixir, but that a Docker container is rapidly becoming the standard “unit of deployment” to the cloud to such an extent that it is practically replacing self-contained binary as the default & simplest deployment option for beginners.
It’s worth pointing out that Docker has other wins too because often times a web app isn’t just setting up Elixir or whatever your programming runtime is.
There’s also your database and probably nginx too (at minimum).
Now it’s no longer a simple “throw a binary on a server” to get your app to run because it depends on those external services. Docker is handy for that because postgres and nginx just become 1 more service in your Docker set up, and you’re able to spin up everything with 1 command.
I don’t think this is really about server deployments.
The use-case for Static Binaries would be CLI tools for web services data processing.
At work we rely heavily in CLI applications that run from cron jobs and having the possibility of using this static binaries could help in the adoption of Elixir, but without them it is one more objection to overcome when trying to make a case for Elixir… you know the usual argument is that GO or Rust can do it!!!
I am a huge fan of Docker, but not the CTO.
Giving your “binary” as a docker package for others to run is not the same as having a true binary that is compiled to the target and does not really depends on anything at all on that same target. This is where Rust and GO shine in relation to Elixir.
I really love what Elixir/Erlang brings to the table but not supporting true binaries is a no go and I bet that a lot have already or will drop Elixir as their future stack due to this and I also bet they will not come to the Elixir channels complaining that we don’t have a true binary.
When we know somebody or some place for the first time the firsts impressions will impact a lot the next interactions with it, thus not having a true binary in a compiled language is like creating a bad impression on first contact that may be the cause of not existing a second contact or a progressive lost of interest in maintain an active relation with it.
So the damage of not having true binaries can be bigger than what Elixir and Erlang core teams and community may think.
Maybe @joeerl and @josevalim may want to put some though on this and revaluate the need to support it in a near future.
