I don't think ruby will ever get to the point where it's useful or a good fit in every context. The optimization goals are pretty clearly laid out: developer performance and happiness over raw speed of the language. A lot of features don't lend themselves to easy performance optimization (open classes, the ability to change methods on individual objects, lots of the metaprogramming features etc.). It's just not ruby's goal to be fast on every platform and in every context. It's often fast enough, though.
Re:Oj – Optimized JSON in Ruby
by whistlerbrk on Tuesday April 25, 2017 @07:51AM
(#14192603)
I agree that Ruby isn't a good fit for every context, but the reasons for Ruby's speed can and are being addressed, this article is extremely accessible and beautiful:
http://chrisseaton.com/rubytruffle/deoptimizing/
A few critical C extensions are missing (OpenSSL):
https://github.com/graalvm/truffleruby
A recent benchmark (FWIW):
https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...
concurrency will always limit ruby.. it will never ever get there and that's ok because that's not ruby's goal.
Ruby has some of the best concurrency support: Fibers and threads are all well-established features. JRuby and Rubinius can handle native threads, no Global Interpreter Lock (GIL) at all.
The downside is most Ruby code bases are reluctant to take advantage of it, or even be thread-safe or fiber-aware, which can make writing apps more challenging than an environment like Node.js where there's established standards and expectations.
Also let's not forget about Guilds...
http://olivierlacan.com/posts/concurrency-in-ruby-3-with-gui...
It would be awesome if Ruby could eventually become useful in every context. I think it'll eventually get there, but on the way there will need a mountain of performance improvements.