Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 5.0: Action Cable, API mode, and more

weblog.rubyonrails.org

Post reply on HN
Print view View original

51–60 of 225 posts

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

#51

Post by bratsche »

davidw wrote: post #19
bcardarella wrote: post #16

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…

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

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

#52

Post by davidw »

bratsche wrote: post #51
davidw wrote: 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…

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.

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

#54

Post by themgt »

bratsche wrote: post #51
davidw wrote: 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…

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

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

#55

Post by ben_jones »

ch4s3 wrote: post #30
mhartl wrote: post #22

Looks like now's a good time to mention that the Ruby on Rails Tutorial book has already been updated for Rails 5: http://railstutorial.org/book Sales actually just launched on Tuesday (announcement here: https://news.learnenough.com/rails-5-edition-of-rails-tutori... ), and you can pick up your copy of the new 4th edition here: http://railstutorial.org/code/launch That link includes a 20% launch discount, which expi…

That's awesome! Michael Hartl is such a great member of the community.

A lot of name dropping on hacker news goes over me head because I've only been in the community a few years. I feel like Michael Hartl will be the name I drop 15 years from now whenever I'm discussing Rails and the origin of "modern" web development.

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

#56

Post by bratsche »

davidw wrote: post #52
bratsche wrote: post #51

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

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

#57

Post by cortesoft »

cyberferret wrote: post #48
stouset wrote: post #38

Earlier quoted context omitted.

Sequel's syntax is strictly less powerful, since Rails' accepts any scope instead of just a hash of conditions. Post.where(id: 1).or Post.joins(:author).where(author: { name: 'John' })

Correct me if I am wrong, but can't the Sequel ORM accomplish this as well? Post.join(:author).where(:author__name => "John") (the above is purely from memory and may have syntax errors). In any case, it lets you drop into raw SQL as a last resort.

Yes, you are correct.

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

#58

Post by jbackus »

dopamean wrote: post #47
jbackus wrote: 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...

I'd love to read more about it. Do you know if he has written anything about this work?

I don't know if he has written about it beyond the docs and various commits. He has talked about it many times on his podcast (which I highly recommend). Here is an episode that talks about the attributes API as well as his Relation#or work: http://bikeshed.fm/8

Definitely also checkout the episodes where he talks about Diesel.

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

#59

Post by rjbwork »

bdcravens wrote: post #45
bcardarella wrote: post #16

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.

A lot of super scalable apps don't necessarily use a "database". They use a heterogeneous set of data stores that are most appropriate for their particular use case. Or maybe they shard, or run a distributed cluster, etc.

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

#60

Post by andrewstuart2 »

karmajunkie wrote: post #46
jsmith0295 wrote: post #21

Earlier quoted context omitted.

They don't have to. With a good architecture (caching, etc) Rails scales well in the overwhelming majority of cases. Performance is only one of many things to worry about when choosing a technology.

I normally see things like caching as an attempt to overcome poor architecture.

It is, sometimes. But a cache hit in 50-150ns beats the pants off of a round trip to the backing database or microservice, which might take tens of milliseconds. That's 100,000-1,000,000x faster.

It's the same reason you'd never find a modern CPU without multiple layers of caching.

Post reply on HN