3 ms·

> but you seem to have a non-factually supported negative bias against Elixir. If deployments are broken for months[1] with no fix in sight, what do you expect

> but you seem to have a non-factually supported negative bias against Elixir. If deployments are broken for months[1] with no fix in sight, what do you expect? I'm currently seeing zero requests per second with Elixr. If the sole maintainer of the sole deployment tool is too disengaged to reply to bug reports I don't care one way or another what sort of performance a product (or its fanbase) are claiming. If the product can't be deployed it's not going to scale. Period. It's a bit silly to talk performance comparisons between Ruby and Elixr as the premise of this article was that Ruby is simply too slow. Are you going to have a harder time scaling Go or Rust than Elixr? I doubt it. I have no idea if you're going to have a harder time scaling Java than Erlang, but Java is popular enough in the enterprise space that finding people with that sort of experience isn't so difficult. The only time I've seen Erlang at scale was with Megacorp's Enterprise Chef deployment. There was easily tens of thousands of dollars in hardware there and the Chef server was still regularly brought to its knees with well less than a thousand total users (and well fewer than that at any given time). 1: https://github.com/bitwalker/distillery/issues/561 https://github.com/bitwalker/distillery/issues/561

pdimitar 8y ago
Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree? As for deployments, I've setup several of them in the last 2 months -- from scratch, and successfully. There's an initial learning curve that might be way too annoying for many. The deployment story is one of the weaker parts of Elixir -- I am not running away from that. As for scaling, you might be mistaken. Erlang/Elixir can be scaled with almost zero effort up to 50 or so machines before you need to introduce special libraries or any extra tooling at all. Of course, you can do the same with many other languages if you put Kubernetes or HAProxy in the picture. Point is, with Erlang/Elixir, it is 99% effortless up to a certain scale which most projects won't ever hit. If you were talking about raw speed however, I can't argue that Erlang/Elixir are just a little faster than a very optimized JS (and still plenty faster than Python, Ruby or PHP). But nobody advocates Elixir for raw number crunching.
- inferiorhuman 8y ago
  > 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.)

pdimitar 8y ago

Open source maintainers burn out. It's a fact of life that's hardly specific to Elixir though, wouldn't you agree? As for deployments, I've setup several of them in the last 2 months -- from scratch, and successfully. There's an initial learning curve that might be way too annoying for many. The deployment story is one of the weaker parts of Elixir -- I am not running away from that. As for scaling, you might be mistaken. Erlang/Elixir can be scaled with almost zero effort up to 50 or so machines before you need to introduce special libraries or any extra tooling at all. Of course, you can do the same with many other languages if you put Kubernetes or HAProxy in the picture. Point is, with Erlang/Elixir, it is 99% effortless up to a certain scale which most projects won't ever hit. If you were talking about raw speed however, I can't argue that Erlang/Elixir are just a little faster than a very optimized JS (and still plenty faster than Python, Ruby or PHP). But nobody advocates Elixir for raw number crunching.

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