News for hackers. Stuff that matters.

A comment on A Brief History of the BEAM Compiler. Parent comment

Re:A Brief History of the BEAM Compiler by qaq on Thursday August 02, 2018 @02:52PM (#17674320)
I think it depends on project domain. perf. is fine for most web apps for example.
[ Parent | on HN ]
Re:A Brief History of the BEAM Compiler by jerrycurly on Thursday August 02, 2018 @03:08PM (#17674508)
>> "perf. is fine for most web apps for example."

That same argument is made for Ruby and look at how many people leave due to slowness

[ Parent | on HN ]
Re:A Brief History of the BEAM Compiler by jxub on Thursday August 02, 2018 @03:14PM (#17674585)
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.
[ Parent | on HN ]
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.

[ Parent | on HN ]
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.
[ Parent | on HN ]
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.
[ Parent | on HN ]