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.
> 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.
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.
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.
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.
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.
That's not the kind of caching GP was referring to, at least not to my reading. I think you'd be hard pressed to find any application level caching that could serve up a cache in the nanosecond range. At best you're looking at sub millisecond range, and that's when the cache lives in memory on the same hardware. Application caching on any modern cloud provider is almost always going to be a network call and best case you're looking at sub-10ms response time. And yes, while I definitely agree that it beats hundreds of ms by a wide margin, it can very easily bite you in the ass if you're not very careful about what gets cached. Caching is a performance hack, pure and simple.
True, I was only citing the figure for memory access times on x86 (according to a quick google). There's certainly going to be more overhead depending on how the cache is implemented, whether it's in memory, or swapped out/deliberately on disk, etc.
That said, I'd call it a fundamental architecture requirement (and one you can't really avoid anyway), given fundamental limitations imposed by the speed of light.
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.
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?
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.
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.
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.
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.