Live data from Hacker News

Rails 5.0: Action Cable, API mode, and more

weblog.rubyonrails.org

41–50 of 225 posts

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

#41
post #27
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.

Performance wise, I wouldn't put Java next to ruby and python, in what workload would the erlang vm beat the jvm?

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

#42
post #27

Earlier quoted context omitted.

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.

Performance wise, I wouldn't put Java next to ruby and python, in what workload would the erlang vm beat the jvm?

I'm talking more about concurrency and distribution models, not raw performance.

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

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

Sean has been doing fantastic, underappreciated work for a long time. Agree here.

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

#44
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…

I know you've receive a gazillion of comments like this in the past but I'm going to do it anyway: THANK YOU. Your work on that book is what got me my first web dev job. I've grown a ton since and have you to thank for it. Thank you so much.

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

#45

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.

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

#46

Earlier quoted context omitted.

unfortunately, i agree with you. Ive moved to elixir for all web work and the erlang vm just blows ruby out of the water at restapi/web services stuff. Im a huge ruby/rails fan though, and have earned a living off the ruby ecosystem. I just dont see how ruby can overcome the vm disadvantage to be honest, though id really like to see them try

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.

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

#47
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?

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

#48
post #38

Earlier quoted context omitted.

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

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.

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

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

I talk about this at length in one of my recent talks but the short version is we wanted to optimize for reuse via named scopes

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

#50
post #27

Earlier quoted context omitted.

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.

Performance wise, I wouldn't put Java next to ruby and python, in what workload would the erlang vm beat the jvm?

low jitter, low latency, high concurrency workloads.
Post reply on HN