The thing is that MRI Ruby is effectively single-threaded (unless you use things like concurrent-ruby which aren't that performant anyway) and threads can be blocked waiting for I/O, in fact they do most of the time, and is in I/O where Erlang really shines thanks to BEAM's nature of lightweight preemptive processes.
Re:A Brief History of the BEAM Compiler
by jashmatthews on Thursday August 02, 2018 @03:47PM
(#17674850)
CRuby is multi-threaded with a GIL. CRuby also supports light-weight cooperative threads called Fibres, which are used to build things like: https://github.com/postrank-labs/goliath/
JRuby has no GIL, JIT, and is significantly faster than BEAM.
Re:A Brief History of the BEAM Compiler
by skrebbel on Thursday August 02, 2018 @03:12PM
(#17674567)
Many of them leave to a BEAM language actually, for speed reasons.
Re:A Brief History of the BEAM Compiler
by jashmatthews on Thursday August 02, 2018 @03:36PM
(#17674763)
CRuby/MRI/YARV is almost as fast as BEAM at web stuff in terms of total throughput and JRuby is significantly faster. Sinatra + Sequel is faster at some things and slower at others. The default Rails setup makes huge tradeoffs away from performance.
That same argument is made for Ruby and look at how many people leave due to slowness