5 ms·

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, wit

by themgt 10y ago

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 years. The advantages from a language/VM level just look impossible for Ruby to overcome, along with a blub effect kicking in.

ch4s3 10y ago
Unless they're able to pull off 3x3 in the next year, I expect Ruby/Rails will start to lose a lot of mind-share. *edit: For clarification, I use Ruby every day and I think its awesome! However, I don't want to see it lose popularity the way Pearl did. I'm concerned that if the language doesn't continue to innovate and improve, that I will lose ground. Lots of new languages have similarly great ergonomics, but get concurrency right, or are faster. I don't think improved concurrency is really on the table for Ruby 3, so I think 3x3 is going to be critical to the long term future of the language. But, that's just my prediction and its likely wrong.
- dmix 10y ago
  3x3?
  - ch4s3 10y ago
    Ruby 3x3 is a plan to make Ruby 3 times faster than Ruby 2.x. Here's some further reading: http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3 http://engineering.appfolio.com/appfolio-engineering/2015/11... https://blog.heroku.com/where_will_ruby_go_now_talking_with_tenderlove_at_railsconf https://blog.heroku.com/where_will_ruby_go_now_talking_with_... https://www.reddit.com/r/ruby/comments/3tje5a/ruby_3x3_ruby_3_will_be_3_times_faster/ https://www.reddit.com/r/ruby/comments/3tje5a/ruby_3x3_ruby_...
- ascendantlogic 10y ago
  Not sure why you're being downvoted for having an opinion. I think Ruby and Rails became the Java of the late 2000's. There's going to be lots of jobs and work for it for many decades to come. But I feel that slowly newer technologies are supplanting it. Such is the way of all technology, though.
jfaucett 10y ago
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
- Scarbutt 10y ago
  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?
  - ch4s3 10y ago
    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 trickier, depending upon what you're experienced with. I like jRuby a lot, but it's a mixed bag for the moment.
    - taf2 10y ago
      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
      - ch4s3 10y ago
        That's not surprising, it has some real problems with certain code, the edge cases are bad sometimes. We had a 20% perf bump, but probably 4x the memory use. That said, it gets better every release, and the JVM tooling is quite nice.
    - pmontra 10y ago
      JRuby is painful to develop with compared to MRI. Running a test suite is slower, everything is slower even if you turn off JIT to startup the JVM faster and do other tricks that I don't remember. That's why Java developers usually work in IDEs that keep compiling and doing hot reloads constantly. Maybe that could apply to JRuby. Anybody here has experiences with a Ruby IDE and JRuby? Do you?
deleted 10y ago
[deleted]
gurkendoktor 10y ago
> 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.
abvdasker 10y ago
The upgrade is anything but easy if an existing application uses protected attributes extensively (removed from Rails 5). Because protected attributes does a shitload of monkey patching it's hard to know exactly what side effects its removal might have, especially in any application that uses nested attributes for mass assignment/initialization of a model's relations.
- rafaelfranca 10y ago
  I'm being working in this kind of application and there is no problem with the "shitload of monkey patching". Most of work was being done in the controller layer to filter the parameters. After you finished this you can safely remove the protected_attributes gem. To make this we created a migration sanitizer for the protected_attributes gem that I plan to integrate in the gem itself very soon.
tcopeland 10y ago
I think the upgrade challenge is going to be the dependencies - declarative_authorization, typus, etc. Ah well, all part of the fun.

by themgt 10y ago

ch4s3 10y ago

Unless they're able to pull off 3x3 in the next year, I expect Ruby/Rails will start to lose a lot of mind-share. *edit: For clarification, I use Ruby every day and I think its awesome! However, I don't want to see it lose popularity the way Pearl did. I'm concerned that if the language doesn't continue to innovate and improve, that I will lose ground. Lots of new languages have similarly great ergonomics, but get concurrency right, or are faster. I don't think improved concurrency is really on the table for Ruby 3, so I think 3x3 is going to be critical to the long term future of the language. But, that's just my prediction and its likely wrong.

dmix 10y ago
3x3?
- ch4s3 10y ago
  Ruby 3x3 is a plan to make Ruby 3 times faster than Ruby 2.x. Here's some further reading: http://engineering.appfolio.com/appfolio-engineering/2015/11/18/ruby-3x3 http://engineering.appfolio.com/appfolio-engineering/2015/11... https://blog.heroku.com/where_will_ruby_go_now_talking_with_tenderlove_at_railsconf https://blog.heroku.com/where_will_ruby_go_now_talking_with_... https://www.reddit.com/r/ruby/comments/3tje5a/ruby_3x3_ruby_3_will_be_3_times_faster/ https://www.reddit.com/r/ruby/comments/3tje5a/ruby_3x3_ruby_...
ascendantlogic 10y ago
Not sure why you're being downvoted for having an opinion. I think Ruby and Rails became the Java of the late 2000's. There's going to be lots of jobs and work for it for many decades to come. But I feel that slowly newer technologies are supplanting it. Such is the way of all technology, though.

jfaucett 10y ago

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

Scarbutt 10y ago
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?
- ch4s3 10y ago
  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 trickier, depending upon what you're experienced with. I like jRuby a lot, but it's a mixed bag for the moment.
  - taf2 10y ago
    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
    - ch4s3 10y ago
      That's not surprising, it has some real problems with certain code, the edge cases are bad sometimes. We had a 20% perf bump, but probably 4x the memory use. That said, it gets better every release, and the JVM tooling is quite nice.
  - pmontra 10y ago
    JRuby is painful to develop with compared to MRI. Running a test suite is slower, everything is slower even if you turn off JIT to startup the JVM faster and do other tricks that I don't remember. That's why Java developers usually work in IDEs that keep compiling and doing hot reloads constantly. Maybe that could apply to JRuby. Anybody here has experiences with a Ruby IDE and JRuby? Do you?

deleted 10y ago

[deleted]

gurkendoktor 10y ago

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

abvdasker 10y ago

The upgrade is anything but easy if an existing application uses protected attributes extensively (removed from Rails 5). Because protected attributes does a shitload of monkey patching it's hard to know exactly what side effects its removal might have, especially in any application that uses nested attributes for mass assignment/initialization of a model's relations.

rafaelfranca 10y ago
I'm being working in this kind of application and there is no problem with the "shitload of monkey patching". Most of work was being done in the controller layer to filter the parameters. After you finished this you can safely remove the protected_attributes gem. To make this we created a migration sanitizer for the protected_attributes gem that I plan to integrate in the gem itself very soon.

tcopeland 10y ago

I think the upgrade challenge is going to be the dependencies - declarative_authorization, typus, etc. Ah well, all part of the fun.