6 ms·

Bakeware: Compile any Elixir application into a single binary

147 points by sergiomattei 5y ago

lwhi 5y ago
I don't know much about elixir but I'm interested. Are there disadvantages to this process?
- eXpl0it3r 5y ago
  I'd assume it's incompatible with LGPL code/libraries (unless it's open source), then again I have no idea how widespread said license is in the Elixir world.
  - dnautics 5y ago
    IIRC LGPL says you have to "convey" the code, not "you must bundle the code with your binary", it could be anything from "email this address to request the code" or "send a SASE to this address and I'll send you a CD-ROM". I believe GPL even lets you charge for the code, I could be wrong about that.
    - ipaddr 5y ago
      You can charge someone for gpl code but you can't expect to get paided if others give away that code.
  - goodpoint 5y ago
    Static linking with LGPL is OK as long as you allow users to relink to other libraries. You can do that by shipping the object files with the binary, or on request, or providing the sources of your application under a closed license, or under any FOSS license.
- goodpoint 5y ago
  Yes: dynamic linking allow receiving OS security updates for any library. With static linking you become responsible for: - tracking down the dependencies used during a build - track where the binary is deployed - follow publishing of vulnerabilities affecting the libraries you used - either backport security fixes, rebuild and deploy the binary or deploy a newer version hoping it does not break anything
spapas82 5y ago
My holy grail would be to (somehow) create a release on Windows (my dev system) and deploy on Linux (our prod servers). However, I have little hope because of the Erlang binaries requirement. Still, you can always hope :)
- lytedev 5y ago
  You can do this with WSL or Docker, can you not?
  - spapas82 5y ago
    I not really sure I don't use WSL nor docker. Even if it was possible I'd really prefer a native solution...
    - wooly_bully 5y ago
      WSL is not 'native' per se, but it's very well-integrated with Windows. I'd give it a look, even if it's just writing a script to run a build command in WSL from the same directory you're developing locally in.
- dnautics 5y ago
  If all goes to plan, I am planning on sponsoring a bounty to get zig cc to cross-compile erlang this summer. In theory, that should enable what you're looking for.
  - sergiomattei 5y ago
    That’s brilliant!
- whalesalad 5y ago
  CI/CD tools can do that for ya
sergiomattei 5y ago
I'm glad Bakeware is applying brainpower to the entry point problem for simple scripts. I'm currently learning Elixir and the biggest initial hurdle was how to actually create an application. Most tutorials teach you through iex but rarely how to actually write a running program or library. Things like "mix run" wouldn't work until I created an app with mix new, then I had to visit the rabbit hole of genservers and supervisors, etc... It's a little complex for beginners and could use some polishing. I can't say that I truly understand it still.
- dudul 5y ago
  I remember being a reviewer for an Elixir book where the first chapter was listing the pros and cons of Elixir, and one of the cons was: it's kind of hard to manage deployment of Elixir applications. My feedback was "hum, that's kind of a turn off for someone trying to learn the language/tech no?" I think the community has been looking for something for a while now and is iterating (too?) quickly. There was erlang releases, there was distillery, now it's elixir releases. There are different ways of configuring in production. It goes a little too fast to keep up with to be honest.
  - dnautics 5y ago
    too fast? I was using Elixir releases two jobs ago.
  - 1_player 5y ago
    It took me 1 hour to convert a production app from Distillery to native releases when Elixir 1.9 released 2 years ago. And deployment in 2021, whatever the language, is best served with containers. Elixir is not harder to deploy than a Django or Node app. In fact, releases and post-deploy ops are pretty well documented: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html Phoenix also has an example multi-stage Dockerfile which is fine for 99% use cases: https://hexdocs.pm/phoenix/releases.html https://hexdocs.pm/phoenix/releases.html
    - dnautics 5y ago
jart 5y ago
Can the cpio command extract the Erlang VM from these binaries? If not, then it shouldn't be called cpio. Operating systems have been known to block binaries that have compressed binaries inside them using novel formats tools don't understand. The design here is very similar to ZIP, which would be a good thing to consider, since that would grant the end user the flexibility to copy the app out of the bakeware shell into their existing Erlang install without having another Erlang get installed.
devoutsalsa 5y ago
Is this fundamentally different than how an escript works?
- filmor 5y ago
  I think it embeds Erlang (erts), escripts require a working Erlang installation.
rad_gruchalski 5y ago
This is pretty neat. One of the reasons why I started looking at golang and stopped writing erlang in 2016 was the single binary deployment. Time to look at elixir with this gem again!

147 points by sergiomattei 5y ago

lwhi 5y ago

I don't know much about elixir but I'm interested. Are there disadvantages to this process?

eXpl0it3r 5y ago
I'd assume it's incompatible with LGPL code/libraries (unless it's open source), then again I have no idea how widespread said license is in the Elixir world.
- dnautics 5y ago
  IIRC LGPL says you have to "convey" the code, not "you must bundle the code with your binary", it could be anything from "email this address to request the code" or "send a SASE to this address and I'll send you a CD-ROM". I believe GPL even lets you charge for the code, I could be wrong about that.
  - ipaddr 5y ago
    You can charge someone for gpl code but you can't expect to get paided if others give away that code.
- goodpoint 5y ago
  Static linking with LGPL is OK as long as you allow users to relink to other libraries. You can do that by shipping the object files with the binary, or on request, or providing the sources of your application under a closed license, or under any FOSS license.
goodpoint 5y ago
Yes: dynamic linking allow receiving OS security updates for any library. With static linking you become responsible for: - tracking down the dependencies used during a build - track where the binary is deployed - follow publishing of vulnerabilities affecting the libraries you used - either backport security fixes, rebuild and deploy the binary or deploy a newer version hoping it does not break anything

spapas82 5y ago

My holy grail would be to (somehow) create a release on Windows (my dev system) and deploy on Linux (our prod servers). However, I have little hope because of the Erlang binaries requirement. Still, you can always hope :)

lytedev 5y ago
You can do this with WSL or Docker, can you not?
- spapas82 5y ago
  I not really sure I don't use WSL nor docker. Even if it was possible I'd really prefer a native solution...
  - wooly_bully 5y ago
    WSL is not 'native' per se, but it's very well-integrated with Windows. I'd give it a look, even if it's just writing a script to run a build command in WSL from the same directory you're developing locally in.
dnautics 5y ago
If all goes to plan, I am planning on sponsoring a bounty to get zig cc to cross-compile erlang this summer. In theory, that should enable what you're looking for.
- sergiomattei 5y ago
  That’s brilliant!
whalesalad 5y ago
CI/CD tools can do that for ya

sergiomattei 5y ago

I'm glad Bakeware is applying brainpower to the entry point problem for simple scripts. I'm currently learning Elixir and the biggest initial hurdle was how to actually create an application. Most tutorials teach you through iex but rarely how to actually write a running program or library. Things like "mix run" wouldn't work until I created an app with mix new, then I had to visit the rabbit hole of genservers and supervisors, etc... It's a little complex for beginners and could use some polishing. I can't say that I truly understand it still.

dudul 5y ago
I remember being a reviewer for an Elixir book where the first chapter was listing the pros and cons of Elixir, and one of the cons was: it's kind of hard to manage deployment of Elixir applications. My feedback was "hum, that's kind of a turn off for someone trying to learn the language/tech no?" I think the community has been looking for something for a while now and is iterating (too?) quickly. There was erlang releases, there was distillery, now it's elixir releases. There are different ways of configuring in production. It goes a little too fast to keep up with to be honest.
- dnautics 5y ago
  too fast? I was using Elixir releases two jobs ago.
- 1_player 5y ago
  It took me 1 hour to convert a production app from Distillery to native releases when Elixir 1.9 released 2 years ago. And deployment in 2021, whatever the language, is best served with containers. Elixir is not harder to deploy than a Django or Node app. In fact, releases and post-deploy ops are pretty well documented: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html Phoenix also has an example multi-stage Dockerfile which is fine for 99% use cases: https://hexdocs.pm/phoenix/releases.html https://hexdocs.pm/phoenix/releases.html
  - dnautics 5y ago

jart 5y ago

Can the cpio command extract the Erlang VM from these binaries? If not, then it shouldn't be called cpio. Operating systems have been known to block binaries that have compressed binaries inside them using novel formats tools don't understand. The design here is very similar to ZIP, which would be a good thing to consider, since that would grant the end user the flexibility to copy the app out of the bakeware shell into their existing Erlang install without having another Erlang get installed.

devoutsalsa 5y ago

Is this fundamentally different than how an escript works?

filmor 5y ago
I think it embeds Erlang (erts), escripts require a working Erlang installation.

rad_gruchalski 5y ago

This is pretty neat. One of the reasons why I started looking at golang and stopped writing erlang in 2016 was the single binary deployment. Time to look at elixir with this gem again!