3 ms·

> Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree? Of course. How many languages have a sin

> Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree? Of course. How many languages have a single deployment story maintained by a single person though? That level of fragility is something I wouldn't put in production. Period. Not even on Linux. And, yes, you could just compile the app in production (and watch the security team lose their shit). Or you can blow everything away for each deployment. Or you could use a tool that's simply less tedious to deploy (e.g. Rust, Go, Java, Clojure, ClojureScript, Javascript). To put it another way, if deploying is a pain, scaling is a pain.

pdimitar 8y ago
> To put it another way, if deploying is a pain, scaling is a pain. I can't understand that argument. Would you please expand? --- I agree it doesn't look very trustworthy that the only viable deployment option in Elixir is kind of stalled lately. Of course. What I am saying is, what we have at the moment works plenty well -- if you can get over the fact that enabling deployment in an Elixir app is needlessly complex. As is said many times here in HN, judging an open-source project by its frequency and recency of commits is quite a flawed strategy.
- inferiorhuman 8y ago
  > 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

> To put it another way, if deploying is a pain, scaling is a pain. I can't understand that argument. Would you please expand? --- I agree it doesn't look very trustworthy that the only viable deployment option in Elixir is kind of stalled lately. Of course. What I am saying is, what we have at the moment works plenty well -- if you can get over the fact that enabling deployment in an Elixir app is needlessly complex. As is said many times here in HN, judging an open-source project by its frequency and recency of commits is quite a flawed strategy.

inferiorhuman 8y ago
> 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