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

31–40 of 225 posts

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

#31

Post by davidw »

rozap wrote: post #27
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 think most folks are finding that distribution in an erlang based application is a lot simpler, because you don't need to pull in things like redis for pubsub, memcached for caching, etc etc. erlang solves a bunch of problems in a rather elegant way that are solved in the java/python/ruby world through gobs of duct tape.

Good point, but I'd see the actual codebase on a single node as the most important thing for most people. Even with Rails you can do a lot with one server.

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

#32

Post by mathgeek »

mmanfrin wrote: post #20
ghayes wrote: post #6

Earlier quoted context omitted.

Been using Elixir / Phoenix as well, and it's been a breath of fresh air. That said, I'm glad that rails has been looking at projects like Phoenix for inspiration as it continues to grow and adapt.

I'm glad that rails has been looking at projects like Phoenix for inspiration Other way around. Phoenix was explicitly inspired by Rails and founded by Rails core members. Elixir was first created by a Rails core member. Phoenix is the performance-really-matters successor to Rails.

You're talking about the original inspiration for Phoenix, while the previous poster is talking about some of the new features in Rails 5. They've both influenced each other.

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

#33

Post by jbackus »

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

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

#34

Post by hartator »

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…

I have tried it only once, what do you think about the management of web sockets compared to the new Rails cable?

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

#35

Post by matthewrudy »

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…

I think performance is compelling, But the bigger win is concurrency.

We run 100s of dynos for our service, but could probably run just a couple if we moved to elixir/otp.

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

#36

Post by bcardarella »

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.

This is mostly an observation I've had of imperative programming vs functional programming. Going back and creating the state of the application in my head is easier when I don't have to find out what else the code is affecting.

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

#38

Post by stouset »

cortesoft wrote: post #18
jesalg wrote: 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)

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

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

#39

Post by gurkendoktor »

themgt wrote: post #7

Looks like a solid and and relatively straightforward upgrade from Rails 4.2. It's hard not to feel Rails has become a bit of a slow-moving behemoth though, with this release four years after 4.0. I've still got a couple clients using 3.2 from 2012 and things aren't that different. Smart money at this point seems like a significant portion of the Rails community could begin moving to Elixir/Phoenix over the coming ye…

> I've still got a couple clients using 3.2 from 2012 and things aren't that different.

Which is exactly what makes Rails 4 and 5 a reasonable choice for slow-moving projects on a budget (i.e. no money to pay for massive library updates every N months).

I think the vocal early adopters are going to jump ship, if they haven't already. But I'm more likely than ever to start new projects on Rails.

Of course, if there's anything in particular that you are missing from Rails, then the lack of fundamental changes can be a showstopper.

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

#40

Post by taf2 »

ch4s3 wrote: post #25
Scarbutt wrote: post #15

Earlier quoted context omitted.

I just dont see how ruby can overcome the vm disadvantage to be honest I don't know how mature it is, but couldn't jruby be the answer to this?

I use jRuby, which is great and an amazing piece of engineering. However, with Rails, you're only see about a 20% speed bump and out of the box it uses too much memory to run on Heroku's free tier. You'll also miss out on the gems with c extensions (for now I think that's about to change). Additionally, there seems to be a performance regression around includes and case statements. Your devops story can also be a bit…

Interesting we saw about a 50% performance hit when trying jruby and also a 15% hit on memory usage- it was a no go for us
Post reply on HN