Euruko 2016 – Ruby is dead, long live Ruby!

It has almost been three weeks since we (me and two colleagues) came back from a wonderful trip to Sofia. Thanks to Mikamai (and I will never stop to be thankful for this! 🤗) we had the opportunity to attend the 2016 Euruko conference.

Considering the list of speakers, all well known for their accomplishments in and out the Ruby community, I was overexcited by the time we had the confirmation of our trip.
Personally I was particularly thrilled to listen to the two keynotes. It doesn’t happen everyday to listen to Matz and José live! 😉
Anyway, enough fangirling!

In this article I would like to report what I was able to note about Matz’s keynote. If you scroll down here and here you may find more info (together with photos and maybe some videos) about it. But now let us begin!

The topic of the keynote is something that rubyists are talking about for a while: Ruby3.

Considering all the hype about this topic, one of the first things that Matz wanted to highlight was the fact that Ruby3 is still pretty much “vaporware”.
And this isn’t actually a bad thing! Vaporware is indeed useful as it fixes goals and objectives at various level of details.
In case of Ruby3, the main goals are the following:

• compatibility
• performance
• concurrency
• typing

There isn’t actually much to say about the first point. Differently from the Ruby 1.8 → 1.9 jump, Ruby3 aims to be fully compatible with Ruby2. All the proposals already submitted as well as the future ones will then need to consider this assumption.

Regarding the second point there is actually a lot more to talk about.
The main goal of Ruby3 in this scope is to be 3 times faster than its predecessor: 3×3!
This may sounds much like a commercial slogan but there is some real concrete work going on here. An explanatory example is represented by Urabe Shyouhei PR #1419. It is known in the wild as “Optimization/Deoptimization” and it is particularly promising considering that Matz cited it in his keynote. If you don’t believe Matz I strongly suggest to take a look at it. It is indeed pretty promising! 😉
Ruby core committers like Shyouhei aren’t however the only ones who are working hard to break the well known and broad assumption that “Ruby is slow”.
JRuby’s Truffle and recent OSS release of IBM OMR are other pretty encouraging signs that now Ruby wants not only to be beautiful (SPOILER ALERT: personal opinion! 😁) but also fast!

Strongly related to the performance point here it is the second one: concurrency.

Yes I know he’s not Matz! But you know what? The second day at Euruko we had the pleasure to listen to José Valim talking about Elixir! And here’s a thing that I really love about Ruby community. It is radically (mostly) openminded. It is made by people who love to study and learn new and better ways to tackle and solve problems.
Sorry for the little digression, but it has to be done! 😛

Anyway, what José stated in his keynote (see picture above) is undoubtedly true but there are two things that I want to stress out here.
First, Ruby was conceived, as a general purpose language, 23 years ago. Just to give you an idea it was born, more or less, when Intel released the first Pentium. At that time, concurrency was something that was needed to solve problems like handling the telephony connectivity at the switches level (( ͡° ͜ʖ ͡°) Erlang). To speak it wasn’t the day by day tool to solve common problems of a software engineer.
Second, Elixir was born in a totally different era in which concurrency is permeant in many more software development areas. To cite one: the Web.
Moreover it really stands on the shoulder of giants (once again ( ͡° ͜ʖ ͡°) Erlang, OTP).
From its birth, Ruby did try to keep up with the emerging concurrency trend but it was (and sill it is) hard considering its roots. By the way, concurrency is in general an hard problem to tackle and even more without the proper abstractions.
Right now Ruby approach towards concurrency is bounded to a tradeoff between performance and safety.

With the GIL (Global Interpreter Lock), or better GVL (Global VM Lock), Ruby chooses safety over performance. However the GIL itself can be actually removed by deleting just a few lines inside Ruby core. Obviously this would lead us all to a danger place of indeterminism, heisenbugs, race conditions and so on.
Moreover the GIL does not magically protect us when we begin to play around with threads (i.e. Thread.new) and this is why we need more powerful abstractions on which we can rely if we want to do multithread programming.
Ruby 1.9’s Fibers were a first step in this direction. But they are not the only abstractions that were studied, investigated and implemented in Ruby ecosystem!
Here’s some others:

• the actor model (e.g. Celluloid)
• the stream model
• the ownership/membership model

The last one in particular has recently received more attention thanks to the work of Ruby core committer and YARV developer Koichi Sasada. Just a few weeks before Euruko he presented at the Ruby Kaigi conference a proposal regarding a possible membership model implementation. So Ruby3 may have a “brand new” abstraction for concurrent programming! This abstraction is by now known as Guilds (yes, exactly like RPG guilds 😁). Underlying they leverage Fibers and green threads to ease developers from the burdens of multithread programming (e.g. the implementation and handling of lock and synchronization strategies). This is accomplished by making available a simple and ease to use API.
A good overview about Guilds can be found here but for more “hardcore” details I strongly suggest to take a look at Koichi’s presentation 😉.

The last topic that Matz addressed in his keynote is definitely one of my favorites. It was right after listening to one of his early talks about it that I decided to make it the main topic of my MSCS thesis: typing!
Regarding this topic, one of the things that I appreciate the most of Matz’s keynote is how he successfully identified a “pendulum” in the scope of programming languages. Here’s a few pictures that should describe what I’m talking about.

Right now static typing seems to be the new hype but we all know that in Ruby we don’t have that.
In Ruby we don’t even have types! Classes aren’t types in Ruby.
In Ruby we have “ducks” 😁 and that’s because we (rubyists and Matz before all) don’t care about types.
We care about behavior. Reasoning about the expected behavior when writing software reduces somehow our brain consumption.

The aforementioned ducks are exactly our expected behaviors!
With them (duck typing) we gain an intrinsically openness towards extensions.
Unfortunately there is no silver bullet and the dynamism granted by duck typing has also some drawbacks:

• unexpected errors at run time
• error messages sometimes difficult to understand
• difficulty to reason about large codebases without tests and documentation

A way to solve these problems could be to add some kind of abstractions like Go interfaces (and so shift towards structural typing) or to add type annotations. Both of these solutions go however against one of the key Ruby concepts: DRY.
Ruby loves to be DRY and relying on “type abstractions” or type annotations would mean to repeat the expected behavior of a piece of software not only explicitly but also more verbosely.
The possible solution suggested by Matz is to rely on something that helps to reconstruct the missing information that developers may need. That is type inference.
With type inference and structural typing, Ruby3 would get “the best of both worlds” (static/dynamic typing).
With something like a “Duck Inference” (trademark ™ and copyright © directly to Matz! 😉) we would get many benefits including:

• improved types (and general) knowledge of software when needed
• no additional brain cost derived from type annotations and abstractions as inferred types does not have names
• possibility to detect more errors at compile time
• improved tools (IDEs) capabilities like refactoring and code completion

Duck inference isn’t perfect though and as Matz says:

The last point that I want to stress out before concluding this already long article refers to the first part of its title: “Ruby is dead”.
It seemed to me that this was the thought of many people attending Matz’s keynote when he said that he doesn’t know when Ruby3 will be ready.
Personally I believe that there is indeed a lot of work to do and this is why it is difficult to state precise deadlines.
But please fellow rubyists don’t turn back your shoulders and be kind of “disrespectful” to the language that have made you what you are. The language that makes you happy.
In any case, don’t lose hope!

Matz is not alone.

Ruby’s community isn’t composed only by “language users” (and lovers!).
There are also many “hardcore” engineers working hard on the language. Koichi Sasada, Urabe Shyouhei, Akira Matsuda, Hiroshi Shibata, Naruse Yui, Terence Lee are just a few names but there are many others!

Cheers and be happy! 😃

P.S: for the ones that want to hear live!!! about what I wrote here I will give a little presentation this Thursday evening (i.e. 13th October) at the first Ruby Night in Milan.
Spoiler alert: I’m not Matz 😝
By the way let me say thank you to the organizer, my friend Davide and once more to Mikamai for hosting the event in its beautiful office!