Comment by gamache | Hacker News Reader

Comment by gamache | Hacker News Reader

Parent Full thread

I love Elixir as much as the next guy, probably more, but I want to temper your enthusiasm a bit:

> it is modern, with modern tooling around the language (e.g. mix, edeliver)

Sort of. Mix is a nice package manager. Edeliver is a series of hacks on deliver, a five-year-old Capistrano clone. But don't expect Elixir to fit into 2015-class deployment systems just yet.

> stack traces are clean, readable, and point you in the right direction most times

Other times, the error happened in another process, all you see is a timeout, and it takes some spelunking. Not uncommon in my experience.

But I'll also add a couple of points:

- the docs system is fantastic, in particular the automatic generation of handsome docs websites, and the `doctest` system which allows example code in your docs to double as test code

- I'm not sure there is anything better than supervisors for isolating and recovering from errors. Defensive programming is one thing, but sometimes your RAM stick gets hit by a cosmic ray. Shit happens; have a plan.

I am not sure how you define 2015-class, but building a release with distillery, and running docker build on a Dockerfile that copies the tarball (that includes everything needed to run your app (ERTS, app code, NIFs, etc)) makes a docker container that you can deploy as you'd expect. If you want to use clustering it's a bit more setup, but I was able to get a simple phoenix app running clustered on Google Container Engine (Kubernetes) in about 4-5 hours, starting with zero knowledge about Kubernetes or Elixir deployment. I pushed my code to github[1], and I did a talk on it at our local Elixir meetup[2].

Now that I have it figured out it's totally painless to upgrade, especially because of the Kubernetes tools. Simply make a new release, build a new container, push it to your docker registry, and then do a rolling update with kubernetes using the new version of the container. You can also add/remove scale on the fly, libcluster handles it all.

[1]https://github.com/bbhoss/k8sexamplephx

[2]https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be...

It fits into industry-standard deployment systems, yes, but not without sacrificing some inherent benefits of the Erlang platform. In particular, hot upgrades and downgrades are no longer there, as Docker images try pretty hard to be immutable. Of course there are also the effects of flushing all server-local cache and/or memoization upon deploys too. Probably a bunch of other stuff I can't think of now also.

So far I've preferred to stick to the Erlang way of doing things because it let me be laziest and it hasn't failed me, but someday I would like to see tools that allow the Erlang way and the e.g., K8s way to work together.

On the other hand, most people seem never to touch hot upgrades, even in Erlang, preferring the traditional rolling update across a cluster of machines. A lot of libraries aren't built for it either.

Yes, hot upgrades sound incredible but the other advantages of docker seem to outweigh them. There is no reason you can't write a script to download the release and do the hotupdate but it feels like you are treating your containers as mutable then which is frowned upon.

Hey liked the video, did you upload your slides anywhere?

I haven't used these seriously yet, but when I looked at the options for deploying Elixir web applications (on a single host), I liked Gatling (https://github.com/hashrocket/gatling), ansible-elixir-stack (https://github.com/HashNuke/ansible-elixir-stack) and, with a few more reservations, Dokku (https://github.com/dokku/dokku) with the appropriate buildpacks.

On a side note, if you work with Ansible, HashNuke's project is worth a closer look even if do not end up using it. It's well-structured and shows how an Ansible role can do both server configuration management and deployment. The pattern works really well; the only downside to this particular implementation is that it has the server pull your code from a Git repository, meaning the server must have access to it, instead of having your development machine copy the code to the server. I'd prefer the latter for security reasons and to match how Ansible works. If that's relevant to your interests, I wrote a hacky Ansible task that shows what that might look like with the same deployment pattern: https://github.com/adhokku/adhokku/blob/master/tasks/deploy-....

Edit: Added a note about the single host.

>> Defensive programming is one thing, but sometimes your RAM stick gets hit by a cosmic ray. Shit happens; have a plan.

This is sort of my big reason for constantly wanting to sit down with erlang/otp/beam. No matter how good your Ada is sometimes you want software that can fall over elegantly.

> But don't expect Elixir to fit into 2015-class deployment systems just yet.

With what you've described -- a package manager that works -- it would seem that it fits pretty well. By 2015-class I'm thinking those systems, like buildpacks, that leverage dependency metadata to build a deployable tarball. What are the parts that seem missing to you?

I explain myself a lot better here: https://news.ycombinator.com/item?id=13447734

What kind of web developer needs to care about cosmic rays and bit flips? Genuinely curious here.

at least those like NASA who use space-grade (radiation hardened?) microchips

That's not what I'm talking about at all.

My issue is that the original commenter listed "resistance" to bit errors as an advantage to using Elixir vs. other languages for web dev.

The question then becomes: who the hell needs bit flip resistance when building a web app?

I'd say it's a metaphor for more likely bugs, the gammaray bitflip being the most meta of them all. What do you think ecc-ram is for?

Exactly. ECC takes care of 99.99% of cases, so I don't see what using Elixir has to do with any of this.

Any web developer whose software runs on computer hardware. Otherwise, you should be fine.

I still don't see why the parent commenter decided to include recovery from cosmic rays as an upside to using Elixir. I'm sure web devs everywhere are throwing out their current tools for this huge advantage! In any case, commodity server hardware already takes care of SEUs through ECC memory.

Memory corruption from cosmic rays may be more common than your intuition suggests. This article cites a 2009 study of a large cluster that found single-bit ECC corrections occurring about 1 per minute per TB, and uncorrectable double-bit errors at a rate of about 1 per year per TB:

http://spectrum.ieee.org/computing/hardware/how-to-kill-a-su....

Whether this is frequent enough to warrant consideration depends on your application, but there are definitely people here who care enough about how their systems recover after errors of this sort that it's not an absurd suggestion.

I use cosmic rays as an example of "errors outside the programmer's control", that's all. My point is that those errors will always exist, and it's desirable to have a backup plan ready.

Reply on news.ycombinator.com