I think the “package and unpack” approach we both happened to have come up with seems to be a good compromise.
I have patched the binaries in clock.linux_x86_64 so they can be run with musl linker, libc and shared libraries that I’ve also included in the package. This process could also be automated and would give us a practical way to use Elixir in places that are currently the domain of Go.
Of course, it would be preferable to get a static build of ERTS but that doesn’t seem to be possible from what I gathered looking at the configure options, right? The bundle would still need to be temporarily unpacked somewhere but at least the linker patching step wouldn’t be necessary.
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.
1 Like
And Docker makes it even less relevant…
It’s a convenience, but only for pretty limited use cases, in my opinion.
1 Like
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.
10 Likes
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.
4 Likes
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.
1 Like
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!!!
2 Likes
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.
3 Likes
Folks, stop expecting that @joeerl and I will come up with the solutions to everything. If it is a problem in the community, the community should get together and solve it.
While we can’t provide the same as Go/Rust, since we don’t compile to native code, we can probably get pretty close, even if it is a self-extractable release.
Also, last time I checked Nerves is able to cross compile the whole OS, NIFs and applications into 20MB. Go look there.
Java also has the same limitations as us and a quick search shows that solutions are available.
19 Likes
Nope, because then you need to manage a Docker repository and your users need Docker and have to take care of organizing the containers your app creates.
Which is precisely why I opened this thread 
4 Likes
So what am I missing here? I mean, at best it perpetuates the myth that installing stuff by copying executables around is a good idea. I think we have package managers on modern Unix systems (not MacOS) for a reason, because nine out of ten times, something more needs to happen (config files in /etc, init scripts, etcetera). There’s a very low number of instances where a software package is just an executable, and since FPM there’s pretty much no reason not to just package for native platform package managers. I guess it’s just laziness?
2 Likes
Maybe the actual killer feature would be a packaging framework that can native create packages from releases.
I guess “generate an fpm invocation” would probably be enough; and yes, it’d be a neat feature for Distillery. Quite trivial to make work cross platform, too, using a decent fpm container.
1 Like
It doesn’t support Windows though, might need to create some kind of MSI or NSIS adapter.
Is there really such a difference between deploying a binary (like go or rust) and a release archive generated by distillery that companies will favor the former over the latter for this reason?
Having said that it’d be nice if BEAM had a better way of handling configuration, especially in the era of containers, but this is probably a topic for another thread.
2 Likes
For CLI tools, yes.
Elixir is absolutely not suited to be a CLI tool, thus wrong use-case.
I still don’t get what is the point of making single executable binary distributions either.
4 Likes
