[amsha]

I'd mostly agree, and the packages you've written (ExRM and Distillery) make releases super easy to build, start, and stop.

The main benefit of Go, I think, is that it can cross-compile builds. Erlang and Elixir don't have any way to do that, so if you develop on Mac and deploy on Linux you'll need to build your release in a VM or on a build server running Linux.

[bitwalker]

You actually don't have to bundle the runtime, but you can also specify an "alternate ERTS", i.e. one that has been compiled for the target architecture, and bundle that one instead. This is how you "cross-compile" releases.

[kungfooguru]

You can include any erts in your target system, so you can take one built on linux, copy it to your mac and use it only at the time when you construct the release tarball.

[chrisseaton]

I thought BEAM was a bytecode VM so why do you need to cross compile anyway? Is the bytecode different on different architectures?

[bitwalker]

Some libraries contain native dependencies, and those have to be cross-compiled. You also need a cross-compiled runtime if you are bundling it and not using one already installed on the target.

[rubiquity]

Releases include the Erlang byte code and the VM as well which needs to be compiled for the platform it will run on.

[chrisseaton]

But why would you want to recompile the VM when you've just changed your program?

And it looks like you can cross compile BEAM anyway. http://erlang.org/faq/implementations.html. It's just a C program isn't it so why wouldn't you be able to?

[GrinningFool]

The ERTS runtime (VM + libraries) are taken from the host and are not built. That said, it is possible to build the runtime for other platforms via cross compilation. [1][2]. I've done this for ARM, but have not tried to generate a release using the cross-platform build.

The beams themselves are cross-platform bytecode, but in practice beam files are not distributed on their own (except for patching). Typically you'll ship them as part of the released package which includes ERTS, your application, and all required dependencies (system libraries, other apps/libraries, and any native dependencies you've introduced). It excludes anything you don't declare as necessary from the final release package

In practice, people will usually use either the official release tooling or third party tooling to create platform-specific releases.

[1] http://erlang.org/doc/installation_guide/INSTALL-CROSS.html [2] http://www2.erlangcentral.org/wiki/?title=Cross_compiling

[gamache]

You're not recompiling the VM, you're just including a copy of it in the release tarball, so that you can copy the tarball to any machine with the same architecture and run it regardless of whether Erlang or Elixir is installed globally on the machine.

The goal of a release is to bundle together everything you need -- your program, the VM that runs it, your config files, and any instructions necessary to upgrade/downgrade from another version of your code.

[xxxx00998978]

He means why not just include the apropiate vm as a binary for any given arch.

[chrisseaton]

But why build the VM for every release then? What is it that needs to be cross compiled if you're just copying a VM build into a tarball? Why not copy an existing build of it in?

[gamache]

The VM is not built for every release, it is copied into the release. The fact that it isn't built for each release is why cross-compilation of releases is not possible.

[solidsnack9000]

I don't think it's common to build and deploy from your laptop once you hit a certain team size -- with builds going through Jenkins &al. -- but maybe this really does a make difference for smaller teams.