3 ms·

> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixi

> Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it. The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. The big win for Go is that it compiles down to a single binary. Ruby you get a single point of entry (script with a shebang). But Elixr/Phoenix? You get a handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the nightmarish deployments that had been broken for months. I couldn't tell if it was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt gem maintainer (which could make Rails deployments a non-starter) but that's easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer for the deployment tool and he's stopped responding to bug reports of any sort. That said, I like Rails. A lot. But ruby is painfully slow and I've learned to push as much logic into the database as possible. So there's a compelling case to be made for an alternative. Unfortunately I've never had any other language give me that much trouble as Elixr has. Personally, I detest Go dependency and build management (and the Google involvement), but the simplicity of concurrency and deployment combined with the breadth of the standard library make a very compelling case for Go IMO. Hell, I would reach for Clojure before Elixr because at least then you're dealing with the comparatively mature Java VM. Personally I've gone down the Rust road, but even then I'm not sure I'd want to deploy a Rust web app in production just yet (although I really do like Rocket).

pdimitar 8y ago
> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular: "With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today." So the first part of your statement is factually false. For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;) > Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success. Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot. I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often. [0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/17306 https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...
- inferiorhuman 8y ago
  > 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.
    - 8y ago
jashmatthews 8y ago
> But ruby is painfully slow and I've learned to push as much logic into the database as possible. Since you said you like Rails, have you tried using Ruby with Sequel instead of AR? AR is incredibly convenient but performance isn't a strong point.

pdimitar 8y ago

> The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community) What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind. > Ecto is still going through some massive changes (ActiveRecord is comparatively stable) As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular: "With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today." So the first part of your statement is factually false. For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;) > Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment. Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success. Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot. I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often. [0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/17306 https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...

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

jashmatthews 8y ago

> But ruby is painfully slow and I've learned to push as much logic into the database as possible. Since you said you like Rails, have you tried using Ruby with Sequel instead of AR? AR is incredibly convenient but performance isn't a strong point.