Looks like now's a good time to mention that the <i>Ruby on Rails Tutorial</i> book has already been updated for Rails 5:<p><a href="http://railstutorial.org/book" rel="nofollow">http://railstutorial.org/book</a><p>Sales actually just launched on Tuesday (announcement here: <a href="https://news.learnenough.com/rails-5-edition-of-rails-tutorial" rel="nofollow">https://news.learnenough.com/rails-5-edition-of-rails-tutori...</a>), and you can pick up your copy of the new 4th edition here:<p><a href="http://railstutorial.org/code/launch" rel="nofollow">http://railstutorial.org/code/launch</a><p>That link includes a 20% launch discount, which expires tonight at midnight PDT.<p>As with previous versions, the new edition focuses on the core principles of web development, so there isn't much Rails 5–specific material in the update, but I am planning standalone Learn Enough tutorials on things like Action Cable and Rails API (<a href="http://learnenough.com/" rel="nofollow">http://learnenough.com/</a>).
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."<p>Here are the docs if anyone is interested: <a href="http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html#method-i-attribute" rel="nofollow">http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...</a>
I see a lot of pro-Erlang/Phoenix pushing in here, which is (as a polite reminder) an announcement about the rails framework. Not to say that one shouldn't, just that I think it's deviating from the main topic in hand. Interestingly, I wanted to find out what's the real reason behind these pushes towards Erlang/Phoenix and I realised the discussion is mostly around how you can save a few bucks worth $20-50 by opting for a faster programming language.<p>Any framework can be tuned to do anything. Rails right now is the only truly comprehensive framework with tight integrations to Coffee, LESS, CSS, etc. As someone who is writing his own framework in Scala, I learned this the hard way after under-estimating how much of work is already done for you in Rails.<p>If you run a business, then all this small talk shouldn't matter as much as how profitable you are. In the end, if your business failed because of your choice of framework (which usually reflects your philosophy), then you need to fix your business model and not the framework.<p>As a polite reminder, I'd like to link to an old comment of mine I made at the time of Rails 4.2:<p><a href="https://news.ycombinator.com/item?id=8201244" rel="nofollow">https://news.ycombinator.com/item?id=8201244</a><p>Have a great weekend everyone!
Passenger author here. Phusion is excited about the Rails 5.0 release! Rails is one of the most productive web frameworks out there, and 5.0 just makes it even better.<p>We have release various Passenger updates to ensure that Passenger plays well with Rails 5, Action Cable etc:<p><a href="https://blog.phusion.nl/2016/02/18/passenger-5-0-25/" rel="nofollow">https://blog.phusion.nl/2016/02/18/passenger-5-0-25/</a><p><a href="https://www.phusionpassenger.com/library/config/nginx/action_cable_integration/" rel="nofollow">https://www.phusionpassenger.com/library/config/nginx/action...</a><p>However we found a bug in Action Cable yesterday which may cause issues with app servers such as Passenger and Puma. Unfortunately the fix didn't make it into 1.0. I recommend anybody who uses Action Cable to apply our patch locally for now: <a href="https://github.com/rails/rails/pull/25615" rel="nofollow">https://github.com/rails/rails/pull/25615</a>
I know that lots of other languages / frameworks compete these days for the title of "most-cutting-edge", but I love working with Rails. There's a lot to be said for the "stability without stagnation" approach. I come from a design background, did not study computer science, and am usually working as a team of one. Rails lets me leverage very finite amounts of time and theoretical knowledge into working software that is elegant, testable, and comprehensible. It is an amazing piece of technology, and I'm happy to see it's still going strong!
I've been following along with Rails 5 for many months now and I've been tracking progress on updating GitLab in our issue tracker[1].<p>Feel free to look at the relevant merge requests and use them as guides to upgrade your own apps :) We're still on 4.2.6 since we have a few gems we're waiting on, but I hope to change that in a month or two!<p>Favorite features are probably the various performance improvements and underlying improvements to the framework, as well as quiet_assets being moved into sprockets-rails.<p>I also wanted to give a shoutout to BigBinary's Rails 5 series, since it's been great for finding out about new features[2].<p>[1]: <a href="https://gitlab.com/gitlab-org/gitlab-ce/issues/14286#note_4272270" rel="nofollow">https://gitlab.com/gitlab-org/gitlab-ce/issues/14286#note_42...</a>
[2]: <a href="http://blog.bigbinary.com/categories/Rails-5/" rel="nofollow">http://blog.bigbinary.com/categories/Rails-5/</a>
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: <a href="https://www.youtube.com/watch?v=OxhTQdcieQE" rel="nofollow">https://www.youtube.com/watch?v=OxhTQdcieQE</a><p>Don't get me wrong, I think Rails is an amazing technology but it doesn't fit the use cases and demands our clients have today.
I personally really love using Rails. It's been very productive for me over the past several years I've been able to make a living off of this.<p>I see a lot of comments here about Elixir/Phoenix. Is the performance gain really that big? I currently serve 2-3 mil requests on Rails per day on around $200 worth of servers with at least one database call per request. In defense of Rails, there are so many libraries out there already built I can get an app up and running fairly quickly. I really think it's a matter whether the tool fits the bill.
Congrats to the contributors and thanks for the hard work pushing this out!<p>Looking forward to Heroku working out of the box[1] and quiet assets moved to core[2]<p>[1] <a href="https://blog.heroku.com/container_ready_rails_5" rel="nofollow">https://blog.heroku.com/container_ready_rails_5</a><p>[2] <a href="https://github.com/rails/sprockets-rails/pull/355" rel="nofollow">https://github.com/rails/sprockets-rails/pull/355</a>
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 <i>that</i> different.<p>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.
To my mind the big news is Turbolink, A simple tech to build SPA with the following roots :
- the robustness & ecosystem of the rails server side (great testing stack & battle tested backend)
- the lightweight approach of rails/javascript, which is opting out of jquery : meaning that SPAs won't have to include jQuery and the whole JS world (client side speed will be greatly enhanced)
- the overall simplicity (no huge javascript stack pilling angular, react, redux, flux, webpack etc...).<p>That's rad.
Odd they didn't mention performance improvements in the blog post. From my understanding, there have been some massive gains (of which, some commits date back to early '15!) One of them which has been killing me, is that model schemas were not preloaded on app boot, which led to the first few dozen requests (depending on how many workers you have on Puma) perform 100+ sql queries and add over 1s to response times. Not only were they not preloaded, but they were not cached across ActiveRecord::Base.connection's<p>Good work rails team!
Concurrency aside, why is Elixir preferred over Ruby when it doesn't even have a native array implementation? No, lists and tuples are no substitute nor are maps with numeric keys as Jose has suggested. If you want an array in Elixir your only option is Erlang's implementation which ain't pretty - <a href="http://erlang.org/doc/man/array.html" rel="nofollow">http://erlang.org/doc/man/array.html</a>. When I raised this issue in the mailing list and on IRC the response was invariably a definsive "I've never needed arrays", "We use tuples for most things in Elixir" or "Array performance characteristics are difficult to optimise in a functional language such as Elixir". I just find this disappointing.
I actually don't like rails' convention over configuration school of thoughts. It makes everything implicit. For any large rails app it's difficult to reason about how things are working, unless you learn all the conventions by heart (by the way, these conventions don't seem to be documented well)
The big things seems to be websockets with Rails cable. I've just skim through the documentation but seems solid. Anyone has a strong opinion on this?
A long awaited release is finally here, Yoohoo!<p>Now, let the job of upgrading begins.<p>Also, I love how everyone found a feature they've been waiting for and celebrating it. Rails, always bring joy (pain comes in few years ;) )
I'm happy to see the new way to render views outside the request cycle: <a href="http://blog.bigbinary.com/2016/01/08/rendering-views-outside-of-controllers-in-rails-5.html" rel="nofollow">http://blog.bigbinary.com/2016/01/08/rendering-views-outside...</a><p>This will be great for, eg, creating reports or receipts in background jobs.
Is anyone aware of a site that the memory footprints of default Rails apps? I know that this may not be the greatest indication of the memory footprint in an actual running app, but I feel it'd still be interesting data. It'd have the be segmented by ruby version, of course.
Anyone else's bundle update spazzing out on resolving dependencies? Guess I'll have to wait until other third party gems get the Rails 5 memo.
All my new development these days centers around node + browserify/webpack with a react frontend, or just plain javascript for small projects.<p>WebSockets would have been a cool addition four years ago. There is little compelling case for new development. Sorry to be so harsh.