Hacker News Reader

Comment by bascule | Hacker News Reader

    Until Rails 4, the core framework didn’t even support concurrent request handling.

Rails has supported multithreaded operation since 2.2: http://guides.rubyonrails.org/2_2_release_notes.html

It never gained widespread adoption because it was off by default. Rails 4 turns it on by default on multithreaded web servers like Puma.

    And even in Rails 4, concurrent request handling is multiplexed on a single CPU core, leaving Rails unable to take advantage of the parallelism of modern architectures.

This isn't true on JRuby, where Ruby threads are 1:1 with JVM threads (which are in turn 1:1 with native threads) that execute in parallel on multiple cores.

At my employer (Square) we run many of our Rails apps in thread safe mode on top of JRuby, providing parallel request processing across multiple cores on a single JRuby/JVM instance.

View on HN

JRuby is of course incompatible with C extensions to Rails; the place I used Rails had such dependencies, and so JRuby was not an option. I agree that JRuby is otherwise preferable to cRuby, though.

I'd be curious to hear how Square has found ruby (independent of rails) to be from a maintenance standpoint.

Check out Xavier Shay's talk on JRuby at Square for more info on our experiences:

https://www.youtube.com/watch?v=hMpd4CzR1f8

> JRuby is of course incompatible with C extensions to Rails

The fact that old-style native extensions are tied to MRI is one of the motivations for Ruby FFI, which provides a common mechanism for interfacing to native libraries on MRI, JRuby, and Rubinius (and maybe some other implementations, as well.)

I assume this wasn't an option for you, but you can sometimes get around this limitation by doing any C-dependent work in a job queue.

> And even in Rails 4, concurrent request handling is multiplexed on a single CPU

Actually, even on YARV you will use more than one CPU, however the GVL won't allow them to be used efficiently.

My point is: there is nothing in Rails forcing it being multiplexed into a single CPU, it is all about which language implementation and web server you choose.

The post is also very inconsistent on its own arguments. If multi-core and being able to share memory in between cores is a criteria, Node is also not a good option compared to what you have in the JVM, Erlang VM, Haskell, Go, etc.

This meme is identical to the trashing mysql gets in 2013 because it doesn't have transactions.

I'm sure when rails 50 ships people will still be claiming it can't multithread.

How is the state of the thread-safety among gems? I have thought a lot about it, but the danger of having thread-issues in the included gems are a bit daunting to be honest.

Not as great as some other language ecosystems, however many people are using Sidekiq, a multithreaded job queue, successfully (and more generally, the Celluloid concurrency framework Sidekiq is based on)

Reply on news.ycombinator.com