Live data from Hacker News

Rails 5.0: Action Cable, API mode, and more

weblog.rubyonrails.org

71–80 of 225 posts

Re: Rails 5.0: Action Cable, API mode, and more

#71
post #3

This has been long awaited: Post.where('id = 1').or(Post.where('id = 2'))

I like the sequel gem's syntax even better: Post.where(:id => 1).or(:id => 2)

This falls apart when you need multiple scopes as it can't tell how to group the 'AND' and 'OR's. The new Rails syntax avoids this problem.

Re: Rails 5.0: Action Cable, API mode, and more

#72
post #52

Earlier quoted context omitted.

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 yo…

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…

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).

Re: Rails 5.0: Action Cable, API mode, and more

#73
post #54

Earlier quoted context omitted.

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 yo…

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

And here is a Ruby vs Java meme from 2006 or so: http://i.imgur.com/1V6rdWV.jpg.

This too shall pass.

Re: Rails 5.0: Action Cable, API mode, and more

#74

We've moved all of our backend offerings from Rails to Elixir/Phoenix. Despite some questioning the value of anything below 100ms response times there is a lot of data backing up the idea that Elixir/Phoenix can lead to a more maintainable and more economical solution. I spoke about this recently at RailsConf: https://www.youtube.com/watch?v=OxhTQdcieQE Don't get me wrong, I think Rails is an amazing technology but i…

Every time I've explored alternatives to try to get those kinds of numbers, it seem the bottleneck is more in the database than the application server.

You should check out https://vimeo.com/171317253. The speakers addresses the database issue in a very interesting way.

Re: Rails 5.0: Action Cable, API mode, and more

#75
post #54

Earlier quoted context omitted.

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 yo…

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

So NIH is the appealing factor of Elixir according to this slide?

Re: Rails 5.0: Action Cable, API mode, and more

#76
post #75
post #54

Earlier quoted context omitted.

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

So NIH is the appealing factor of Elixir according to this slide?

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.

Re: Rails 5.0: Action Cable, API mode, and more

#77
post #33

I feel bad for Sean Griffin. He spent over a year overhauling the internals of ActiveRecord to add this attributes API. His work dramatically improves coercion and type enforcement for ActiveRecord users. Seems weird for this to only get a non-descriptive bullet point in "other highlights." Here are the docs if anyone is interested: http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...

Super appreciated! Great work Sean. This kind of deep structural improvement will pay dividends for years.

Re: Rails 5.0: Action Cable, API mode, and more

#78
post #19

Earlier quoted context omitted.

> more maintainable I get that the Erlang VM is really nice for some things (I made my first contribution to it in 2004!), but I'm curious about the above statement, as I haven't had the time to dig into Elixir/Phoenix yet.

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 yo…

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?

Re: Rails 5.0: Action Cable, API mode, and more

#79
I personally really love using Rails. It's been very productive for me over the past several years I've been able to make a living off of this.

I see a lot of comments here about Elixir/Phoenix. Is the performance gain really that big? I currently serve 2-3 mil requests on Rails per day on around $200 worth of servers with at least one database call per request. In defense of Rails, there are so many libraries out there already built I can get an app up and running fairly quickly. I really think it's a matter whether the tool fits the bill.

Re: Rails 5.0: Action Cable, API mode, and more

#80
post #79

I personally really love using Rails. It's been very productive for me over the past several years I've been able to make a living off of this. I see a lot of comments here about Elixir/Phoenix. Is the performance gain really that big? I currently serve 2-3 mil requests on Rails per day on around $200 worth of servers with at least one database call per request. In defense of Rails, there are so many libraries out th…

It's around 12 times faster in the general sense. Your mileage may vary.

If you spend $200 you could theoretically hosting the same product on $50 worth of hardware.

Post reply on HN