6 ms·

I'm still fairly new with Elixir/Phoenix (as I think most of us still are), but so far I feel intuitively that it's more maintainable and I admit that I don't h

I'm still fairly new with Elixir/Phoenix (as I think most of us still are), but so far I feel intuitively that it's more maintainable and I admit that I don't have the experience or numbers to back that up yet. There are some things that you simply must use other tools for in Rails, because it can't maintain state like Erlang can. Once you start adding in these other things, you're no longer just a "Rails app" but you're really creating an entire system. Now you've got different things you potentially need to test, and you're adding in extra stuff to your system to monitor and measure the different parts of your system. You might do the same thing in Erlang/Elixir, but you also might not. You can potentially keep your entire "system" inside Erlang, either in one node or distributed. So right away simply having that option sounds like a huge improvement in maintainability. You've got everything running in Erlang, monitored and supervised in Erlang/Elixir, more easily testable using ExUnit or whatever. And I think @bcardella talked about this in his RailsConf presentation (linked somewhere in the comments here).. but the performance you get from Elixir/Phoenix is potentially a huge improvement in maintenance. How much time have people spent in NewRelic or whatever measuring and tuning their Rails apps, getting the caching and everything working just right? People are writing Phoenix apps with zero caching that are performing better than Rails with caching. When people aren't having to go debug and diagnose these kinds of performance problems they get to work on actual features. Again, some of this is just my intuition on it more than real experience to back it up. I've built a couple apps with Phoenix and I do enjoy it more. They're not big enough for the performance to really matter, but I do feel strongly that they're simpler because I'm keeping everything in Elixir code and not having to use, for example, Sidekiq in order to do anything async.

davidw 10y ago
I would love to see someone take a deep dive into why their Phoenix thing is "so much faster" than with Rails. I mean really look at the whole stack from the VM, to different pieces of the framework like views and DB interaction. Erlang definitely does concurrency well, but it is not that much faster than Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the work and look at where Phoenix is eking out those gains.
- perishabledave 10y ago
  It sounds like you're undervaluing concurrency. Concurrency is huge for a web application. If you were say doing image manipulation or other DSP where you needed "raw speed" you'd want to choose a language like C, Go, Rust. But in a web application you're handling hundreds, thousands, to millions of requests per second; concurrency is crucial for that kind of throughput. A developer on my team did some quick benchmarks and found that that Phoenix gives an order of magnitude better performance than Rails. Thats not negligible.
  - davidw 10y ago
    Yes, concurrency is better - way better - in Erlang, but I'd like to see things broken down in detail. Show times with 1 client, 10, 100 etc...
- bratsche 10y ago
  I would love to see that too! The one thing that comes to mind is that since each process has its own isolated memory space, Erlang's GC is not a "stop the universe" kind of thing, the GC can run in parallel with other processes. (edit: again, this is just intuition on my part, I haven't remotely done the deep dive you're talking about)
- percept 10y ago
  I was a bit surprised by its performance in the last TechEmpower benchmarks: roughly equivalent to Rails and other Ruby-based solutions (PHP, too). It could be a case of not yet being optimized for the tests, but I was expecting much more impressive numbers out of the box (particularly after the full-court press on the boards and blogs).
  - asdf1234 10y ago
    The Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. This has happened with a bunch of different languages/frameworks in the past and until the errors in the implementation are sorted out the benchmarks are basically meaningless. Chris McCord talks about it here https://www.reddit.com/r/elixir/comments/48ke69/any_reason_why_elixirphoenix_did_so_badly_in/d0ko6ai https://www.reddit.com/r/elixir/comments/48ke69/any_reason_w...
themgt 10y ago
Exactly this. It's easy to do 'rails new' and push to Heroku, but when you've got redis, memcache, the worker process & scheduler etc etc you're really maintaining your own ecosystem. It's a lot of where time gets spent on production Rails apps. Here's that slide, I believe: http://i.imgur.com/QzTCJS8.png http://i.imgur.com/QzTCJS8.png
- mavelikara 10y ago
  And here is a Ruby vs Java meme from 2006 or so: http://i.imgur.com/1V6rdWV.jpg http://i.imgur.com/1V6rdWV.jpg. This too shall pass.
  - mooreds 10y ago
    What's old is new again!
- sayelt 10y ago
  So NIH is the appealing factor of Elixir according to this slide?
  - bcardarella 10y ago
    Considering that nearly all of those features were in Erlang before the other services listed I don't think NIH applies. Elixir just exposes the Erlang tools.
  - bratsche 10y ago
    No. In a Rails system you've got Rails running, maybe across X number of instances with Unicorn or whatever, sitting behind nginx. If you want to have a long-running request or websocket you've typically used Go or Node or Elixir. If you need to store state between requests you may be using Redis. For background jobs and general async things you've probably got something like Sidekiq. Erlang already has an http server that Elixir apps are using now, it's called Cowboy. It's not that Elixir is creating their own just because. One of the reasons nginx is often used for Rails apps is to handle static assets, because Rails just isn't as well-equipped to handle those. Cowboy seems to be fine with handling static assets, so a lot of people just take nginx out of the equation for an Elixir app. Typically Rails apps have used something else like Node or Go or Elixir for long-running requests or websockets. Maybe that will change with ActionCable, maybe not. Either way, Elixir/Phoenix happen to be quite good at this already. Phoenix's equivalent to ActionCable is called Phoenix Channels and it's able to handle 2 million+ websocket connections on a single server, which is pretty cool I think. Rails apps use redis to manage state between requests. Elixir apps just don't need something like this. Elixir doesn't have something different, it just happens to be easy to store state between requests already. Rails apps may use Sidekiq or something to deal with background jobs or async operations. This is another case where Elixir doesn't have anything special to occupy that role in the stack, it just happens to be good at that already. Most of these properties are things that Elixir inherited from Erlang, which has been around for years. I wish I had started learning Erlang a long time ago but unfortunately it just wasn't really on my radar. But really the only thing on this list which is a relatively recent thing is Phoenix Channels, and I don't think that's really a NIH thing. At least, certainly not any more than ActionCable is.
fchopin 10y ago
What I use Rails for these days is (1) as a backend to our SPAs, so ActiveRecord, Rails controllers, and a view to serve JS assets and CSS via the Asset Pipeline, and (2) to serve Active Admin. I see there is Ecto, Brunch, and ExAdmin for Phoenix, to cover our primary bases I spoke of, in Elixir/Phoenix. For those that have switched to Phoenix, and have experience with these three- was it as smooth transition? What are the significant gaps, if any?
- RobertKerans 10y ago
  A Devise equivalent. There are a number of alternatives, but I've found them all a little raw: with many Rails projects, I know I can just add Devise, and be confident it'll Just Work with minimal work. Valim said he wasn't interested in building a Devise equivalent for Phoenix - I think the reasoning was that each context is different enough in its own way that a monolithic one-size-fits-all solution like Devise isn't preferable, which is fair enough. But authentication is a pain, and carefully wiring up slightly immature solutions is a little hairy. I've found this only really applies to CRUD-like, Rails-like projects, so about half of the projects I've built, so YMMV: it's maybe just me making the jump from Rails and expecting things to be more similar than they are. Ecto is good; it's not quite an ORM, so there were a few WTFs when I tried to do things the same way, but on balance I prefer the Ecto approach; a Linq-like query language I like better than a [somewhat magic] ORM, the way it seperates concerns is good, and (in common with most of Phoenix) the way it works is pretty transparent. Not quite mature yet, though Ecto 2 seems to cover most of the functionality I found to be missing in 1.x. I work primarily front-end,and I always had issues with the asset pipeline. I've found Brunch to be fantastic - there are always going to be a few issues when dealing with NPM, but other than that, I think they picked the absolute simplest JS-based task runner, and having direct access to the JS ecosystem is great. Brunch has been almost zero-config for me, has Just Worked with only a few `rm -rf node_modules`

davidw 10y ago

I would love to see someone take a deep dive into why their Phoenix thing is "so much faster" than with Rails. I mean really look at the whole stack from the VM, to different pieces of the framework like views and DB interaction. Erlang definitely does concurrency well, but it is not that much faster than Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the work and look at where Phoenix is eking out those gains.

perishabledave 10y ago
It sounds like you're undervaluing concurrency. Concurrency is huge for a web application. If you were say doing image manipulation or other DSP where you needed "raw speed" you'd want to choose a language like C, Go, Rust. But in a web application you're handling hundreds, thousands, to millions of requests per second; concurrency is crucial for that kind of throughput. A developer on my team did some quick benchmarks and found that that Phoenix gives an order of magnitude better performance than Rails. Thats not negligible.
- davidw 10y ago
  Yes, concurrency is better - way better - in Erlang, but I'd like to see things broken down in detail. Show times with 1 client, 10, 100 etc...
bratsche 10y ago
I would love to see that too! The one thing that comes to mind is that since each process has its own isolated memory space, Erlang's GC is not a "stop the universe" kind of thing, the GC can run in parallel with other processes. (edit: again, this is just intuition on my part, I haven't remotely done the deep dive you're talking about)
percept 10y ago
I was a bit surprised by its performance in the last TechEmpower benchmarks: roughly equivalent to Rails and other Ruby-based solutions (PHP, too). It could be a case of not yet being optimized for the tests, but I was expecting much more impressive numbers out of the box (particularly after the full-court press on the boards and blogs).
- asdf1234 10y ago
  The Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. This has happened with a bunch of different languages/frameworks in the past and until the errors in the implementation are sorted out the benchmarks are basically meaningless. Chris McCord talks about it here https://www.reddit.com/r/elixir/comments/48ke69/any_reason_why_elixirphoenix_did_so_badly_in/d0ko6ai https://www.reddit.com/r/elixir/comments/48ke69/any_reason_w...

themgt 10y ago

Exactly this. It's easy to do 'rails new' and push to Heroku, but when you've got redis, memcache, the worker process & scheduler etc etc you're really maintaining your own ecosystem. It's a lot of where time gets spent on production Rails apps. Here's that slide, I believe: http://i.imgur.com/QzTCJS8.png http://i.imgur.com/QzTCJS8.png

mavelikara 10y ago
And here is a Ruby vs Java meme from 2006 or so: http://i.imgur.com/1V6rdWV.jpg http://i.imgur.com/1V6rdWV.jpg. This too shall pass.
- mooreds 10y ago
  What's old is new again!
sayelt 10y ago
So NIH is the appealing factor of Elixir according to this slide?
- bcardarella 10y ago
  Considering that nearly all of those features were in Erlang before the other services listed I don't think NIH applies. Elixir just exposes the Erlang tools.
- bratsche 10y ago
  No. In a Rails system you've got Rails running, maybe across X number of instances with Unicorn or whatever, sitting behind nginx. If you want to have a long-running request or websocket you've typically used Go or Node or Elixir. If you need to store state between requests you may be using Redis. For background jobs and general async things you've probably got something like Sidekiq. Erlang already has an http server that Elixir apps are using now, it's called Cowboy. It's not that Elixir is creating their own just because. One of the reasons nginx is often used for Rails apps is to handle static assets, because Rails just isn't as well-equipped to handle those. Cowboy seems to be fine with handling static assets, so a lot of people just take nginx out of the equation for an Elixir app. Typically Rails apps have used something else like Node or Go or Elixir for long-running requests or websockets. Maybe that will change with ActionCable, maybe not. Either way, Elixir/Phoenix happen to be quite good at this already. Phoenix's equivalent to ActionCable is called Phoenix Channels and it's able to handle 2 million+ websocket connections on a single server, which is pretty cool I think. Rails apps use redis to manage state between requests. Elixir apps just don't need something like this. Elixir doesn't have something different, it just happens to be easy to store state between requests already. Rails apps may use Sidekiq or something to deal with background jobs or async operations. This is another case where Elixir doesn't have anything special to occupy that role in the stack, it just happens to be good at that already. Most of these properties are things that Elixir inherited from Erlang, which has been around for years. I wish I had started learning Erlang a long time ago but unfortunately it just wasn't really on my radar. But really the only thing on this list which is a relatively recent thing is Phoenix Channels, and I don't think that's really a NIH thing. At least, certainly not any more than ActionCable is.

fchopin 10y ago

What I use Rails for these days is (1) as a backend to our SPAs, so ActiveRecord, Rails controllers, and a view to serve JS assets and CSS via the Asset Pipeline, and (2) to serve Active Admin. I see there is Ecto, Brunch, and ExAdmin for Phoenix, to cover our primary bases I spoke of, in Elixir/Phoenix. For those that have switched to Phoenix, and have experience with these three- was it as smooth transition? What are the significant gaps, if any?

RobertKerans 10y ago
A Devise equivalent. There are a number of alternatives, but I've found them all a little raw: with many Rails projects, I know I can just add Devise, and be confident it'll Just Work with minimal work. Valim said he wasn't interested in building a Devise equivalent for Phoenix - I think the reasoning was that each context is different enough in its own way that a monolithic one-size-fits-all solution like Devise isn't preferable, which is fair enough. But authentication is a pain, and carefully wiring up slightly immature solutions is a little hairy. I've found this only really applies to CRUD-like, Rails-like projects, so about half of the projects I've built, so YMMV: it's maybe just me making the jump from Rails and expecting things to be more similar than they are. Ecto is good; it's not quite an ORM, so there were a few WTFs when I tried to do things the same way, but on balance I prefer the Ecto approach; a Linq-like query language I like better than a [somewhat magic] ORM, the way it seperates concerns is good, and (in common with most of Phoenix) the way it works is pretty transparent. Not quite mature yet, though Ecto 2 seems to cover most of the functionality I found to be missing in 1.x. I work primarily front-end,and I always had issues with the asset pipeline. I've found Brunch to be fantastic - there are always going to be a few issues when dealing with NPM, but other than that, I think they picked the absolute simplest JS-based task runner, and having direct access to the JS ecosystem is great. Brunch has been almost zero-config for me, has Just Worked with only a few `rm -rf node_modules`