
Rails 5.0: Action Cable, API mode, and more - tenderlove
http://weblog.rubyonrails.org/2016/6/30/Rails-5-0-final/#yay
======
mhartl
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](http://railstutorial.org/book)

Sales actually just launched on Tuesday (announcement here:
[https://news.learnenough.com/rails-5-edition-of-rails-
tutori...](https://news.learnenough.com/rails-5-edition-of-rails-tutorial)),
and you can pick up your copy of the new 4th edition here:

[http://railstutorial.org/code/launch](http://railstutorial.org/code/launch)

That link includes a 20% launch discount, which expires tonight at midnight
PDT.

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 ([http://learnenough.com/](http://learnenough.com/)).

~~~
ch4s3
That's awesome! Michael Hartl is such a great member of the community.

~~~
ben_jones
A lot of name dropping on hacker news goes over me head because I've only been
in the community a few years. I feel like Michael Hartl will be the name I
drop 15 years from now whenever I'm discussing Rails and the origin of
"modern" web development.

~~~
ch4s3
I agree. Have you heard his interview[1] on Software Engineering Daily? He's a
really interesting guy.

[1][http://softwareengineeringdaily.com/2016/01/11/learning-
rail...](http://softwareengineeringdaily.com/2016/01/11/learning-rails-with-
michael-hartl/)

------
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...](http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html#method-
i-attribute)

~~~
dopamean
I'd love to read more about it. Do you know if he has written anything about
this work?

~~~
rabidferret
Most in depth I went was probably in
[http://m.youtube.com/watch?v=PUuYAksQWg4](http://m.youtube.com/watch?v=PUuYAksQWg4)
but I discuss it in pretty much every talk I give.

You can also just ping me on Twitter and I can talk about it more. :)

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

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.

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.

As a polite reminder, I'd like to link to an old comment of mine I made at the
time of Rails 4.2:

[https://news.ycombinator.com/item?id=8201244](https://news.ycombinator.com/item?id=8201244)

Have a great weekend everyone!

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

You're right basically, but the migration wave from rails to phoenix has
noticeably started, and it shows.

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

Actually, the high performance stuff and Rails-y organization of phoenix is
just something to give you immediate benefits and a sense of familiarity. It
attracts people and give them a reason to try it out. Beginners praise it, but
it's by far not the actual reason to keep pushing phoenix. Just like

"hey, it works like rails, you can do everything with it like rails does, so
there is just a small learning curve and we have orders of magnitude better
performance!"

> Any framework can be tuned to do anything.

Yes this is true. You can also write OOP assembly or use vim as a bitmap
editor like paint. The point is: while you can theoretically do everything
with mostly everything, the results will differ a lot and the way to these
results will vary a lot.

With phoenix, there is no "magic" (people complain about this in rails!),
everything is simple, explicit and straightforward. You also do not need many
third-party tools like redis, sidekiq or memcached. This greatly simplifies
the application code, reducing brittle constructs/bindings.

Currently, Rails still has the edge when it comes to gems, many things are
readily available. This helps when "getting started" for typical app
scenarios.

But a few weeks in, maintenance is the most important factor when it comes to
development speed. Here Phoenix wins by a large margin. Less dependencies,
easier code, less performance tuning, less bugs (compiler/dialyzer/...
arguably).

> Rails right now is the only truly comprehensive framework with tight
> integrations to Coffee, LESS, CSS, etc.

The asset pipeline of rails can be quite a pain in the ass. Phoenix went a
different way by integrating brunch, the probably easiest of the node.js task
runners, which mostly doesn't even need custom configurations. (npm install
--save brunch-less, your less files are integrated as you'd expect. Same for
coffeescript, ...).

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

The development speed _does_ matter. when you waste time optimizing things,
fixing bugs with dependencies or stuff like that, you aren't shipping
features. Moving fast is crucial for startups.

And then there is scaling. Phoenix is known to handle large loads with ease,
and probably most startups can go a long way before they even have to consider
horizontal scaling. Not having to think about this is worth more than the
money you'd throw at servers to scale up rails (which, as you said, isn't
needed in that quantity in phoenix either).

And just a personal note on top of this: Once functional programming/elixir
"clicks" for you, translating business requirements into working code is _so
much_ easier as functional data transformation with pipes than having to deal
with forests of class structures. For many cases, it just makes more sense
(and is easier to read, maintain, extend and test).

\---

Finally, the actual big win of phoenix is BEAM/OTP. Performance aside, the
thought model of OTP just makes so much sense and simplifies building
reliable, distributing systems a lot. I'd argue that OTP is the true reason
people are blown away, elixir simplifies the syntax/reduces boilerplate, and
phoenix on top makes getting started a breeze, looks like rails on the
surface, and once you get into how OTP works, you're hooked.

~~~
steveklabnik
I really like Elixir and Erlang, but haven't found he time to play with
Phoenix. But...

    
    
      > You're right basically, but the migration wave from
      > rails to phoenix has noticeably started, and 
      > it shows.
    

People have previously said this about:

    
    
      * Clojure
      * Node
      * Go
    

And lots of things before that.

~~~
anonyfox
Sure! But this time (tm) it's different. Phoenix is a direct drop-in
replacement for rails, with a bunch of strong benefits on top. Getting
productive for a rails developer should be 1-2 weeks max, since one already
knows how the framework works conceptually. The truly cool stuff happens when
one learns how stuff works beneath the surface.

While you're around: Elixir/Erlang in itself is a rather slow language when it
comes to number crunching performance. The canonical way currently is to write
NIFs in C for these parts. But if this native code crashes, the reliability
promise of BEAM goes out the window. For me it would make _much_ more sense to
write native extensions in Rust. Have you ever considered to include a plugin
to "mix", Elixir's build tool, that allows one to ship Rust source files
alongside the Elixir application, which then at compile time fetch a Rust
compiler, compiles the code on the current platform and generates a NIF? This
would be _so_ huge.

~~~
davidw
> direct drop-in replacement

Uh...

"Drop-in replacement is a term used in computer science and other fields. It
refers to the ability to replace one hardware (or software) component with
another one without any other code or configuration changes being required and
resulting in no negative impacts."

That's not the case at all with Phoenix, nice as it may be.

~~~
anonyfox
Point to you. I should have looked up the actual definition.

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

We have release various Passenger updates to ensure that Passenger plays well
with Rails 5, Action Cable etc:

[https://blog.phusion.nl/2016/02/18/passenger-5-0-25/](https://blog.phusion.nl/2016/02/18/passenger-5-0-25/)

[https://www.phusionpassenger.com/library/config/nginx/action...](https://www.phusionpassenger.com/library/config/nginx/action_cable_integration/)

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:
[https://github.com/rails/rails/pull/25615](https://github.com/rails/rails/pull/25615)

------
katabasis
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!

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

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!

Favorite features are probably the various performance improvements and
underlying improvements to the framework, as well as quiet_assets being moved
into sprockets-rails.

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

[1]: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/14286#note_42...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/14286#note_4272270) [2]:
[http://blog.bigbinary.com/categories/Rails-5/](http://blog.bigbinary.com/categories/Rails-5/)

------
bcardarella
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](https://www.youtube.com/watch?v=OxhTQdcieQE)

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.

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

~~~
bratsche
I'm still fairly new with Elixir/Phoenix (as I think most of us still are),
but so far I feel intuitively that it's more maintainable and I admit that I
don't have the experience or numbers to back that up yet.

There are some things that you simply must use other tools for in Rails,
because it can't maintain state like Erlang can. Once you start adding in
these other things, you're no longer just a "Rails app" but you're really
creating an entire system. Now you've got different things you potentially
need to test, and you're adding in extra stuff to your system to monitor and
measure the different parts of your system. You might do the same thing in
Erlang/Elixir, but you also might not. You can potentially keep your entire
"system" inside Erlang, either in one node or distributed. So right away
simply having that option sounds like a huge improvement in maintainability.
You've got everything running in Erlang, monitored and supervised in
Erlang/Elixir, more easily testable using ExUnit or whatever.

And I think @bcardella talked about this in his RailsConf presentation (linked
somewhere in the comments here).. but the performance you get from
Elixir/Phoenix is potentially a huge improvement in maintenance. How much time
have people spent in NewRelic or whatever measuring and tuning their Rails
apps, getting the caching and everything working just right? People are
writing Phoenix apps with zero caching that are performing better than Rails
with caching. When people aren't having to go debug and diagnose these kinds
of performance problems they get to work on actual features.

Again, some of this is just my intuition on it more than real experience to
back it up. I've built a couple apps with Phoenix and I do enjoy it more.
They're not big enough for the performance to really matter, but I do feel
strongly that they're simpler because I'm keeping everything in Elixir code
and not having to use, for example, Sidekiq in order to do anything async.

~~~
davidw
I would love to see someone take a _deep_ dive into why their Phoenix thing is
"so much faster" than with Rails. I mean really look at the whole stack from
the VM, to different pieces of the framework like views and DB interaction.
Erlang definitely does concurrency well, but it is not that much faster than
Ruby in terms of "raw speed". I'd be fascinated to see someone actually do the
work and look at where Phoenix is eking out those gains.

~~~
anonyfox
Some bigger details why phoenix is so fast despite erlang being a "slow"
language:

\- macros: fancy syntax and "magic" can be resolved at compile-time. Less work
to do on runtime.

\- templates: they get handled at compile-time, too, resulting in functions
with blobs of binaries. This matters a lot, since a specific template-binary
exists only once throughout the application and gets re-used whenever needed.
This way you get near instant templating, instead of the usual string
processing on every request.

\- dispatching code like the routing that must be done on every request is
like rails a DSL, but actually a macro, that gets compiled down to basic
pattern matches, which is extremely fast.

\- the concurrency model is extremely lightweight, handling more requests
and/or doing more stuff per request is much more efficient hardware-wise.
Indirect performance gain.

Just a few points that have a very noticeably impact, there are probably more.
It boils down to the erlang vm's concurrency and pattern matching performance,
plus elixir's compile-time macros and the fact that they treat strings as
immutable binaries.

~~~
davidw
> macros

All well and good, but Erlang/beam code is not _that_ fast.

> templates

Ruby's templates are parsed into code that stays in memory, too, so it's not
like they're re-parsed each and every time.

> routing

Perhaps clever use of pattern matching helps here. But my point is: someone
should dissect these things in a real-world-ish application to see what's
actually true.

> concurrency

Yes, but let's be precise. Everyone knows Erlang's concurrency is way better
than Ruby's. The claim was 'fast' though. As well as maintainable, which seems
curious given that there are no really old Phoenix apps out there.

~~~
anonyfox
> but Erlang/beam code is not that fast.

True, no doubt. You wanted a comparison why phoenix is faster than rails. And
simply doing things at compile time reduces work at runtime. In Ruby, all
Metaprogramming must be done at runtime, for example via method_missing
trickery (been there, done that).

> Ruby's templates are parsed into code that stays in memory, too, so it's not
> like they're re-parsed each and every time.

This is actually not the same. A single immutable blob of binary (elixir
strings) which is shared throughout the whole application can leverage
hardware caching better. Jose could answer this probably better than I can do.

> someone should dissect these things in a real-world-ish application to see
> what's actually true.

Moz.com recently had fun with Elixir [1]. You may also have a look at
[https://www.youtube.com/watch?v=OxhTQdcieQE](https://www.youtube.com/watch?v=OxhTQdcieQE)
from latest RailsConf.

> The claim was 'fast' though

Well at least I know that BEAM processes are far lighter than eg: goroutines.
Also there is a per-process GC, so no "stop the world", much smaller units for
individual collects, and when a process finishes before the heap grows full,
it can be discarded directly.

> maintainable, which seems curious given that there are no really old Phoenix
> apps out there

Fair enough.

Personally I'd not wait until a software stack is a decade old before even
considering it. I have at least worked on Elixir/Phoenix projects for many
months now on-off with multiple colleagues, and it was/is still pure joy.
Aesthetically pleasing syntax helps (broken window syndrome I guess), plus
functional programming style in general, plus phoenix' foundation in "plug"
and the clear modularity. "Let it crash" with supervisors also is incredibly
robust, and robustness in itself leads to less maintenance costs.

\---

[1] [https://moz.com/devblog/moz-analytics-db-
free/](https://moz.com/devblog/moz-analytics-db-free/)

~~~
davidw
All good points. As I keep saying, I'm an Erlang fan. I actually used it at my
last job, and have used it on and off since 2004-ish. It definitely has some
advantages, but I'm just curious where it's actually beating Rails, and with
what kinds of workloads and test methodology and so on.

Stuff like "Erlang processes are lighter" matters in some contexts, but not in
a straight up speed contest. It matters a lot when you start trying to handle
a bunch of concurrent connections, so maybe that's where we're getting some of
the claims from.

~~~
anonyfox
I'd say you really should have a look into
[https://www.youtube.com/watch?v=OxhTQdcieQE](https://www.youtube.com/watch?v=OxhTQdcieQE)
. A really great presentation, including numbers and real world backup data,
plus conceptual overviews.

~~~
davidw
It's pretty good, but a bit hype-y.

Functional programming is not an 'antidote' to having to go back and read old
code or necessarily understanding it easily.

It references this:

[http://sorentwo.com/2016/02/02/caching-what-is-it-good-
for.h...](http://sorentwo.com/2016/02/02/caching-what-is-it-good-for.html)

Which is interesting, but I don't see source code. 1.5-2X is pretty
believable, but quite a bit less than "12 times" \- which someone quoted here.

~~~
anonyfox
I can personally confirm above 10x improvements over rails, but can't Share
the code :)

Depends on what you're doing though. Seems to excel when having low CPU
intensive workloads but high traffic pressure from my experience.

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

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.

~~~
sergiotapia
It's around 12 times faster in the general sense. Your mileage may vary.

If you spend $200 you could theoretically hosting the same product on $50
worth of hardware.

~~~
rebelidealist
That saving of $150 is equivalent to one hour of pro dev work time. It's
hardly worth converting unless Elxir / Phoenix is much more productive and
maintainable.

~~~
rdtsc
> That saving of $150 is equivalent to one hour of pro dev work time.

Fair point, unless you have more customers. Then it can start to add up
quickly. And by customers it means requests as well. Being able to handle
large traffic spikes and continous connections is a game change from what I
found.

Moreover. A huge benefit is using the BEAM VM, I use Erlang (but same VM) and
I have seen major advantages being able to trace, debug, hotpatch a running
system. Some parts of the cluster would be crashing and restarting for a
while, and there would be no need to wake everyone up. It can be fixed in the
morning kinda deal.

An interesting observation to think about -- importance of fault tollerance
grows as quickly or quicker than concurrency. What I mean is if you have a
service that handles more concurrent requests, it now becomes are lot more
important to have solid fault tollerance, because a single failed request,
maybe causing a segfault, can kill all of them for example.

That is a bit hard to understand unless you see it practice. You can think of
it this way -- it doesn't matter if the system can handle 100K requests /
second. If it is not fault tollerant, when it crashes it handles 0 requests /
second. Depending how crappy the uptime is, you can average those number and
get something that's pretty low.

~~~
gtaylor
> Being able to handle large traffic spikes and continous connections is a
> game change from what I found

This isn't specific to Elixir/Phoenix/Beam.

> Some parts of the cluster would be crashing and restarting for a while, and
> there would be no need to wake everyone up

Like any well-designed system that separates concerns. Again, this isn't
language or framwork-specific.

This stuff is what frustrates me most about the vocal early adopting crowd. If
it makes your team vastly more productive, that sounds like a great win for
you. If you subjectively like it better, that's also perfectly valid. But
citing resilience, efficiency, scalability, and handling traffic spikes seems
thin -- these are all things that can easily be attained with just about any
well-factored system on any number of languages/frameworks.

Get off my lawn.

~~~
rdtsc
> these are all things that can easily be attained with just about any well-
> factored system on any number of languages/frameworks

Not sure what your point it. I shared my experience working with systems, you
can share yours (if you have any).

Yes, you can write any of the stuff in assembly. Erlang, Java, Rust, all can
be written in assembly. You can serve web pages in that too, and even create
distributed system by twiddling bits directly in the network card's receive
buffer.

> This stuff is what frustrates me most about the vocal early adopting crowd.

Lol, early adopters ;-) Erlang turned 30 this year. It is probably older than
the median age of people reading this comment.

> Again, this isn't language or framwork-specific.

Again, point to where I said "nothing like this can be done in any other
frameworks". Code reload -- can do it in Java. But you'll get paper cuts.
Python -- can spawn an OS process to get fault isolation, but, can only spawn
so many. Distribution -- spin another instance in AWS, talk gRPC with it, but
now you are paying more money and have another library to maintain.

> But citing resilience, efficiency, scalability, and handling traffic spikes
> seems thin

Well would you prefer a whitepaper? It is an informal conversation. Do you ask
for proof / benchmarks / whitepapers every time you talk to someone at a
meetup? That must be fun.

But if you want a fun reference, pick up your smartphone, navigate to a web
page. Does it work? Good. There is 50% chance it works because Erlang works.
There you go, scalability, resilience and efficiency ;-) can share that at the
next meetup's beer hour.

~~~
nurettin
Since this is a thread about RoR5, perhaps the "early adopters" comment was
targeted at the proponents of Phoenix/Elixir who fail to demonstrate any of
the shortcomings of their chosen framework rather than people who have been
relying on the reliability of their resilient BEAM to efficiently make a
living for the past 30 something years.

------
paws
Congrats to the contributors and thanks for the hard work pushing this out!

Looking forward to Heroku working out of the box[1] and quiet assets moved to
core[2]

[1]
[https://blog.heroku.com/container_ready_rails_5](https://blog.heroku.com/container_ready_rails_5)

[2] [https://github.com/rails/sprockets-
rails/pull/355](https://github.com/rails/sprockets-rails/pull/355)

------
vassy
By looking at the comments you'd assume a new version of Phoenix got released.

~~~
igravious
Agreed. It's getting pretty annoying. Every Rails post that hits the front
page now feels like it's getting hijacked/side-tracked by Elixir/Phoenix
evangelists.

~~~
ascendantlogic
Well a few years back it was hijacked by the Node evangelists. People always
have to advocate for their newest toy(s).

------
themgt
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
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
3x3?

~~~
ch4s3
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...](http://engineering.appfolio.com/appfolio-
engineering/2015/11/18/ruby-3x3)

[https://blog.heroku.com/where_will_ruby_go_now_talking_with_...](https://blog.heroku.com/where_will_ruby_go_now_talking_with_tenderlove_at_railsconf)
[https://www.reddit.com/r/ruby/comments/3tje5a/ruby_3x3_ruby_...](https://www.reddit.com/r/ruby/comments/3tje5a/ruby_3x3_ruby_3_will_be_3_times_faster/)

------
jesalg
This has been long awaited:

    
    
      Post.where('id = 1').or(Post.where('id = 2'))

~~~
ch4s3
Seriously, .or() always felt like a glaring omission.

~~~
pmontra
I wrote it in SQL when I needed it, after all I knew SQL before AR came
around. An OR is very rare and probably that's why it landed only in version
5.

Another implementation is Post.where(id: [1, 2]) which is SELECT * FROM posts
WHERE id IN (1, 2). I guess a db would compile it into exactly the same code
(dbs use different terms but that's what it is) but the performances could be
different inside AR/Arel.

~~~
chippy
Post.find([1,2])

Works in Rails 4

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

That's rad.

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

Good work rails team!

------
bratsche
This is pretty cool. I've kind of moved on to Elixir and Phoenix for my web
stuff these days, but it's still nice to see Rails going strong.

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

~~~
mmanfrin

      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.

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

------
cutler
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 -
[http://erlang.org/doc/man/array.html](http://erlang.org/doc/man/array.html).
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.

~~~
tedmiston
Python lacks a native array too but its list type seems to do just fine. What
is it you want to do that you that requires an array?

~~~
cutler
Python's lists are lists in name only when compared with lists in functional
languages. Whilst Python may offer additional array/vector implementations its
lists are equivalent to arrays or vectors in other languages such as Ruby.

------
fantasticsid
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)

~~~
pmontra
If you are a Rails developer you know all the conventions and they help you at
finding code with only an editor and a file manager. No need of IDEs. It's
very easy to learn a new application, unless the original developer wanted to
be clever, which usually means that was one of his/her first Rails projects.

However there are other school of thoughts and not everybody likes the Rails
way. It's fair and it's a big world with space for every opinion and tool.

~~~
fantasticsid
I never learned 'all conventions'. There are countless cases where I had to
dig into source code to find out how a certain feature is working/how it works
with another feature/when the abstraction does not work the way I want

I guess being implicit just makes it harder to find out which part of
abstraction is leaking when it happens..

But again I'm not a good rails programmer. I was just never a fan of how
conventions play such a big part, and was not well documented.

------
Fuffidish
Nice! The Turbolinks 5 presentation was really impressive

------
hartator
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?

------
desireco42
A long awaited release is finally here, Yoohoo!

Now, let the job of upgrading begins.

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 ;) )

------
juandazapata
Thanks to the community for all the hard work on this release.

------
nathan_long
I'm happy to see the new way to render views outside the request cycle:
[http://blog.bigbinary.com/2016/01/08/rendering-views-
outside...](http://blog.bigbinary.com/2016/01/08/rendering-views-outside-of-
controllers-in-rails-5.html)

This will be great for, eg, creating reports or receipts in background jobs.

~~~
bigtunacan
This was possible in Rails 4 using the Render Anywhere gem.

------
justinzollars
I wish I had API mode 4 years ago

~~~
steveklabnik
You could have! It was reverted, so we made [https://github.com/rails-
api](https://github.com/rails-api) in the meantime, and this was finally
(literally four years later) pulled upstream now.

~~~
justinzollars
haha Thats funny. I was always hacking my way around this problem and landed
on Padrino and Flask.

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

~~~
robgering
Not memory footprints per se, but RubyBench tracks iterations per second and
object allocation across a wide selection of common Ruby/Rails programs.

[https://rubybench.org/](https://rubybench.org/)

------
fn
Finally! Congrats to all the contributors!

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

------
xjlin0
I love Action Cable!

------
albasha
I am very jealous as a Django developer. They decided to keep Channels as a
third-party package after all, maintained by a single guy :(

~~~
tedmiston
Kind of.

48 contributors total (Yes, Andrew is doing most) -
[https://github.com/andrewgodwin/channels/graphs/contributors](https://github.com/andrewgodwin/channels/graphs/contributors)

It sounds like it wasn't decided to keep 3rd party as much as decided not to
not combine _yet_ :

> The feedback I got during the proposal process for putting Channels into
> Django 1.10 (it did not get in before the deadline, but will still be
> developed as an external app with 1.10) was valuable; some of the more
> recent changes and work, such as backpressure and the local-and-remote Redis
> backend, are based on feedback from that process, and I imagine more tweaks
> will emerge as more things get deployed on Channels.

[https://www.aeracode.org/2016/6/16/philosophy-
channels/](https://www.aeracode.org/2016/6/16/philosophy-channels/)

You can still use Channels today in 1.8–1.10.

[https://blog.heroku.com/in_deep_with_django_channels_the_fut...](https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django)

This project is very much in the spotlight, was heavily discussed at PyCon,
etc. I don't think it's going anywhere.

------
iamleppert
All my new development these days centers around node + browserify/webpack
with a react frontend, or just plain javascript for small projects.

WebSockets would have been a cool addition four years ago. There is little
compelling case for new development. Sorry to be so harsh.

~~~
pekk
That's fine, and I don't use Rails either - but this post was about Rails.
People who use or want to use Rails are likely to benefit from the new
features. Even if that number has declined somewhat, it's still a lot of
people, that still merits development, it's still a topic of interest to
others on HN, and it's easy to avoid if you find that you aren't personally
interested.

Besides which, I can't see that a switch from Rails to Node is going to have
any strong advantage if you are equally proficient in each. If they're really
about the same, this would boil down to "I like JS more than Ruby," which is
not about the technology so much as personal feelings.

