Ruby 3.0.0 RC1

I&#x27;m glad to see they&#x27;re picking up native type-hinting. I don&#x27;t like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it&#x27;s official.<p>The concurrency stuff is cool but I can&#x27;t really comment on it, my rule is &quot;if you&#x27;re going to even think about threads, just use Java or go&quot; since concurrency is so nice there.<p>I really wish ruby had won over python as the &quot;general purpose scripting language&quot;, I like it better. For example, I wish all the &quot;big data&quot; tooling was written in Ruby. But python is just the lingua franca. PySpark, Pandas, Airflow, etc are all python. I&#x27;m not really going anywhere with this, just lamenting I don&#x27;t get to do more Ruby in my day job. I recently switched to writing python at home just because my productivity is so much better because I&#x27;ve memorized the standard library better from using it for years at work.

First pattern matching, and now type-hinting and message-passing actors. Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby?<p>Not to say I’m not grateful! I’m mostly an Elixir dev, but since the Erlang Runtime System sucks at POSIX (bad at pipelines, bad at exit codes, bad at trapping signals, etc.) I personally switch to Ruby when I need a glue language. It’s nice to see the available paradigms in these (actually very different) languages “coming together”, in a way where I can spend less time mentally mode-switching, and just keep thinking in (functional, pattern-matching, concurrent-actor) terms.<p>Just think how pleasant it will be to write a “show a spinner as you poll a resource in the background” code in Ruby, now that we’ve got actors. :)

In case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: <a href="http:&#x2F;&#x2F;software.rochus-keller.ch&#x2F;are-we-fast-yet_crystal_ruby_lua_node_i386_results_2020-12-20.pdf" rel="nofollow">http:&#x2F;&#x2F;software.rochus-keller.ch&#x2F;are-we-fast-yet_crystal_rub...</a> and <a href="http:&#x2F;&#x2F;software.rochus-keller.ch&#x2F;are-we-fast-yet_crystal_ruby_lua_node_i386_results_2020-12-10.pdf" rel="nofollow">http:&#x2F;&#x2F;software.rochus-keller.ch&#x2F;are-we-fast-yet_crystal_rub...</a>.<p>I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%).<p>See here for more information about the benchmark suite: <a href="https:&#x2F;&#x2F;stefan-marr.de&#x2F;papers&#x2F;dls-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stefan-marr.de&#x2F;papers&#x2F;dls-marr-et-al-cross-language-...</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;smarr&#x2F;are-we-fast-yet" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;smarr&#x2F;are-we-fast-yet</a>. In contrast to other benchmarks the focus is on ideomatic language use and representative results (i.e. not just some random micro benchmarks) suited for inter-language comparisons.

Anecdotally, since I got away from Ruby, working on software became way more productive and tolerable.<p>Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd.<p>Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a dozen languages were involved.<p>Insert Confused Jackie Chan meme.

Love the move to gemify standard library. This is a perfect mix of batteries included but also makes it easy to upgrade bits of the standard library over time between releases. Great way to prevent stagnation.

I&#x27;ve been writing Python for close to a decade off and on. I&#x27;m just now dipping my toes into Ruby and have found it quite fun- excited to dig deeper into this and Rails :D

I really dislike this:<p><pre><code> {b: 0, c: 1} =&gt; {b:} p b #=&gt; 0 </code></pre> It is so weird that a variable named `b` is initialized after an hash-key-like symbol is referenced (`b:`). It&#x27;s something you&#x27;ve never seen in Ruby before and that I hope I&#x27;ll never encounter along my career as Ruby on Rails developer.

RC1 is a little bit late for a Christmas Day release (which is a long-running Ruby tradition). I wonder if they’ll make it, and if so, if 3.0.0 will be less stable than usual.

Could someone familiar with the Fiber&#x2F;Async thing explain how does this differ from Python&#x27;s (or Node&#x27;s)? How come Python (and Node) needs explicit awaits but Ruby seems to &quot;just work&quot;?

There now is:<p>- Fibers<p>- Also fibers, but scheduled<p>- Threads (Not what you&#x27;d normally calla thread, because GVL)<p>- Ractors (what you&#x27;d normally call a thread)<p>I wouldn&#x27;t say this is a bad thing per se, but I imagine it will be quite confusing for people trying to learn the language.

I look at Ruby and I think of Dart.<p>Not from language semantics perspective..but specialisation in a very narrow usecase and around DX. But really unbeatable in that usecase.<p>all racehorses are one-trick really.

I hadn&#x27;t been following the proposals for and development of Ruby 3 very closely, so Ractors were a nice surprise when I finally did check in.

Well done to all contributors, looking forward to giving it a spin and learning about the additions. Has anyone had experience using RBS yet?

This seemed sparse on JIT updates, I read the linked NEWS page and while it had some feature updates, I&#x27;m curious how this is going. I believe JIT went from &quot;likely to speed up most applications significantly&quot; to &quot;may sometimes speed things up, default is off and needs more work.&quot;<p>Anyone know the status of using JIT in something like a rails app?

Awesome early Christmas surprise!

D

I tried Ruby over 10 years ago and while I really enjoyed the language itself (vastly more than, say, Python for instance) I was completely put off by the insanely poor performance of the interpreter. I remember trying to get it to run on a rather slow FreeBSD box back then and just loading a simple script with a few dependencies would take literally seconds! Perl and Python were easily an order of magnitude faster.<p>Have things improved on that side?