3 ms·

> I can't understand that argument. Would you please expand? See the Github issue linked (and the related issues). Distillery is known broken. Who cares if E

> I can't understand that argument. Would you please expand? See the Github issue linked (and the related issues). Distillery is known broken. Who cares if Elixr or Erlang scales really well if you can't even get it deployed? That Distillery is, for all intents and purposes, abandoned is secondary. It wasn't left in a usable state.

pdimitar 8y ago
I agree it doesn't look well but you simply can't claim that Distillery is broken. The last stable version works just fine. Interesting to see an outside take on the situation though. Thank you. (EDIT: Also, in the issue it's pointed out that a newer Erlang OTP release fixes the problem.)
- inferiorhuman 8y ago
  Uh, there's also a suggestion that setting NODE_NAME will fix the solution. Unfortunately the issue remains open because Distillery has been abandoned in a non-working (which, by definition, is broken) state. I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here. All have passive support for the BSDs, and yet all three have actively maintained native packages (rustup and/or ports tree). That neither the Distllery author nor the BSD users have managed to come up with a solution is quite telling — deployments on Elixir are nightmarishly complex. I'm most familiar with Rust, so in contrast if you look at the the BSD specific issues you'll find a very engaged userbase. Deploying unmaintained software in production is sometimes a necessity with legacy stuff but is almost always a bad idea for new deployments. Elixir has plenty of passionate advocates but no good deployment or support stories. That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't things I would be comfortable deploying in production (Linux or not) no matter how many compelling ideas they dangle in front of you. And, as has been pointed out, Elixr doesn't offer significant (if any performance benefits) over modern Ruby (and by extension Java, Go, or Rust). vOv

pdimitar 8y ago

I agree it doesn't look well but you simply can't claim that Distillery is broken. The last stable version works just fine. Interesting to see an outside take on the situation though. Thank you. (EDIT: Also, in the issue it's pointed out that a newer Erlang OTP release fixes the problem.)

inferiorhuman 8y ago
Uh, there's also a suggestion that setting NODE_NAME will fix the solution. Unfortunately the issue remains open because Distillery has been abandoned in a non-working (which, by definition, is broken) state. I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here. All have passive support for the BSDs, and yet all three have actively maintained native packages (rustup and/or ports tree). That neither the Distllery author nor the BSD users have managed to come up with a solution is quite telling — deployments on Elixir are nightmarishly complex. I'm most familiar with Rust, so in contrast if you look at the the BSD specific issues you'll find a very engaged userbase. Deploying unmaintained software in production is sometimes a necessity with legacy stuff but is almost always a bad idea for new deployments. Elixir has plenty of passionate advocates but no good deployment or support stories. That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't things I would be comfortable deploying in production (Linux or not) no matter how many compelling ideas they dangle in front of you. And, as has been pointed out, Elixr doesn't offer significant (if any performance benefits) over modern Ruby (and by extension Java, Go, or Rust). vOv