Hacker News Reader

Comment by Lio | Hacker News Reader

> my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there.

I could see reasons for preferring Java over Ruby but concurrency isn't one of them considering that Concurrent-Ruby running on JRuby gives you access to all of Java's concurrency tooling.[1]

1. https://github.com/ruby-concurrency/concurrent-ruby

View on HN

you can still go with jruby and have best of both worlds.

Or bake it into a task graph and use the gmake executor.

I've tried on a project, but incompatibility with some libraries (gems) made it impossible. I guess it's very much like PyPy.

I think parallelism is just not part of the Ruby ecosystem anyway, at least in the present (possibly in the future, who knows).

Rails released officially support for multithreading long ago, but it was broken. And there is a Ruby global lock, anyway (3.0 will have true parallelism, although in alpha).

Well the parallelism issues doesn't exist in the jruby world, but yes, gems with C extensions normally don't work out of the box with jruby, but in another hand you can call java straight from ruby. That's so powerful and often better than the gems - if you know how to right ruby and wrap the java classes with ruby! So as many times said along this thread, ruby isn't rails. I have a project running in a government agency with jruby. It was a port of an old Java SWT application and we rewrote it in jrubyFX. The project was such a pleasure!

Reply on news.ycombinator.com