4 ms·

One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc). After a

One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc). After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly.

lpsz 11y ago
Yes, and the standard Go workspace layout (and therefore not even needing a makefile) is great.
rubiquity 11y ago
Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.
- nailer 11y ago
  Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.
  - rubiquity 11y ago
    There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deployment http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy... Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go. 0 - https://github.com/bitwalker/exrm https://github.com/bitwalker/exrm 1 - https://github.com/smpallen99/exrm-rpm https://github.com/smpallen99/exrm-rpm
  - jake_morrison 11y ago
    We deploy using Erlang "releases", which bundle the Erlang vm along with your application and it's dependencies into a tarball with a script to run the application. You don't need to install Erlang on the target system, just unpack and run. We use "mix release" to build the tarball, scp to the server and unpack, then run using an upstart unit which runs "exec su -s /bin/sh -c 'exec "$0" "$@"' myuser -- /path/to/deploy/directory/bin/myapp foreground" It's pretty painless. We are automating with Fabric now, but will likely be switching to Ansible soon.
  - simoncion 11y ago
    AFAIK, bytecode compiled on one Erlang system runs on any other. Bytecode is stored in .beam files, and -AIUI- .beam files are always forward compatible. However, I'm not sure if bytecode compiled with an Erlang version >=17.0 will run on earlier versions of Erlang if it makes use of maps. (Maps are a new type that was introduced in Erlang 17.0.) I should really test this.

lpsz 11y ago

Yes, and the standard Go workspace layout (and therefore not even needing a makefile) is great.

rubiquity 11y ago

Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.

nailer 11y ago
Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto? Forgive me if I've missed something. I'm just getting excited about elixir at this stage.
- rubiquity 11y ago
  There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deployment http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy... Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go. 0 - https://github.com/bitwalker/exrm https://github.com/bitwalker/exrm 1 - https://github.com/smpallen99/exrm-rpm https://github.com/smpallen99/exrm-rpm
- jake_morrison 11y ago
  We deploy using Erlang "releases", which bundle the Erlang vm along with your application and it's dependencies into a tarball with a script to run the application. You don't need to install Erlang on the target system, just unpack and run. We use "mix release" to build the tarball, scp to the server and unpack, then run using an upstart unit which runs "exec su -s /bin/sh -c 'exec "$0" "$@"' myuser -- /path/to/deploy/directory/bin/myapp foreground" It's pretty painless. We are automating with Fabric now, but will likely be switching to Ansible soon.
- simoncion 11y ago
  AFAIK, bytecode compiled on one Erlang system runs on any other. Bytecode is stored in .beam files, and -AIUI- .beam files are always forward compatible. However, I'm not sure if bytecode compiled with an Erlang version >=17.0 will run on earlier versions of Erlang if it makes use of maps. (Maps are a new type that was introduced in Erlang 17.0.) I should really test this.