[HN Gopher] Bakeware: Compile any Elixir application into a sing...
___________________________________________________________________
Bakeware: Compile any Elixir application into a single binary
Author : sergiomattei
Score : 88 points
Date : 2021-06-08 05:01 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jart wrote:
| 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.
| spapas82 wrote:
| 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 :)
| dnautics wrote:
| 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.
| lytedev wrote:
| You can do this with WSL or Docker, can you not?
| spapas82 wrote:
| 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 wrote:
| 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.
| whalesalad wrote:
| CI/CD tools can do that for ya
| sergiomattei wrote:
| 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 wrote:
| 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.
| pmontra wrote:
| It's going fast because the original ways were (euphemism)
| sub optimal. Example: compiling configuration into a release
| was clearly wrong based on my experience with other
| languages. A small mistake and another run through CI/CD with
| production down vs edit a configuration file and restart?
| Ouch. Maybe inevitable with a lot of servers but very wrong
| for a single server application.
| dnautics wrote:
| too fast? I was using Elixir releases two jobs ago.
| 1_player wrote:
| 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
|
| Phoenix also has an example multi-stage Dockerfile which is
| fine for 99% use cases:
| https://hexdocs.pm/phoenix/releases.html
| lwhi wrote:
| I don't know much about elixir but I'm interested.
|
| Are there disadvantages to this process?
| goodpoint wrote:
| 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
| eXpl0it3r wrote:
| 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 wrote:
| 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 wrote:
| You can charge someone for gpl code but you can't expect to
| get paided if others give away that code.
| goodpoint wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-08 23:01 UTC)