Congratulations Ruby team! I'm excited to hear about the performance improvements. It seems like JIT could be a huge win since calling a method requires checking all kinds of possibilities that are almost always not used, but might be. I would love to keep all the power & fun of Ruby without worrying so much about performance.<p>Speaking of optimizing method calls: now that it's been a few years, I wonder what Ruby folks think about refinements. Are you using them? Are they helpful? Horrible?<p>I remember reading from the JRuby folks that refinements would make Ruby method calls slower---and not just refined calls, but <i>all</i> method calls [1], although it sounds like that changed some before they were released [2]. It seems like people stopped talking about this after they came out, so I'm wondering if refinements are still a challenge when optimizing Ruby? I guess MRI JIT will face the same challenges as the Java implementation?<p>[1] <a href="http://blog.headius.com/2012/11/refining-ruby.html" rel="nofollow">http://blog.headius.com/2012/11/refining-ruby.html</a><p>[2] <a href="https://github.com/jruby/jruby/issues/1062" rel="nofollow">https://github.com/jruby/jruby/issues/1062</a>
> Add a new alias then to Kernel#yield_self. [Feature #14594]<p>It might seem strange that they lead with this new feature, but `yield_self` can greatly improve the Ruby chainsaw, and `then` makes it more accessible.<p>The style of writing a Ruby method as series of chained statements has a non-trivial effect on readability and conciseness. `then` lets you stick an arbitrary function anywhere in the chain. They become more flexible and composable, with less need to interrupt them with intermediate variables that break the flow.<p>I've been using `ergo` from Ruby Facets for years ... largely the same thing ... and the more I used it the more readable I find my old code now. Funny how adding one very simple method can have more effect than so many other complex, high effort changes.
> We’re going to implement method iniling in JIT compiler, which is expected to increase Ruby’s performance in order of magnitude<p>An order of magnitude as in .. 10x? This seems too good to be true. Half the arguments against Rails melt away like butter if that's truly the case.<p>Anyone with a better understanding of the details care to comment on the likelihood of these performance gains being actually realised, and if not, what we might realistically expect?
@darkdimius[0], the person who tweeted the referenced tweet in the article, was arguably the primary contributor to Dotty[1] behind Martin Odersky (Dotty will be Scala 3, the next major version of the language).<p>Once he finished his doctorate at the EPFL, off to Stripe he went, bye bye Scala. Tough industry, on the one hand Scala benefits from a revolving door of high level EPFL doctoral students, and on the other the talent pool shifts around as students come and go.<p>Money talks, companies like Stripe have a leg up in that they can fund full-time engineers to work on projects, whereas institution backed projects typically have a much smaller pool of long-term engineers to rely on (JetBrains, for example, has something like 40 full-time engineers working on Kotlin/KotlinJS/Kotlin Native).<p>[0] <a href="https://github.com/DarkDimius" rel="nofollow">https://github.com/DarkDimius</a>
[1] <a href="https://github.com/lampepfl/dotty" rel="nofollow">https://github.com/lampepfl/dotty</a>
What’s the current sentiment as for what will ultimately lead to the best performance of executing Ruby?<p>From my uneducated perspective, seems like Graal VM could become the de facto Ruby deployment stack.<p><a href="https://github.com/oracle/truffleruby" rel="nofollow">https://github.com/oracle/truffleruby</a>
There is another announcement from RubyKaigi 2018 related to performance.<p>Rubex - A Ruby-like language for writing Ruby C extensions.<p><a href="https://github.com/SciRuby/rubex" rel="nofollow">https://github.com/SciRuby/rubex</a>
I wish though, that except for eval and exec, that the majority of Ruby code could get an incremental/LTO JIT similar to HotSpot and a GC like C4 rather than an inc gen GC.
> Unlike ordinary JIT compilers for other languages, Ruby’s JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native cod e.<p>Oh dear god.
I wonder if Matz may consider even just adopting Crystal in the future, considering it is almost 99% compatible with Ruby and has 10x-20x performance gains out of the box.
Everything in Ruby happens at runtime. Even the definition `class X` becomes a runtime `Class.new` invocation. It's imperative from the inside out. Even a JIT is compiler won't and can't solve the fundamental flaws permanently baked into the language. If you want performance, Ruby probably shouldn't be the first tool you reach for.