How is software born? It’s not quite the first question you expect to hear uttered by a keynote speaker at a programming conference, but this is the genial, Japanese creator of the Ruby programming language, Yukihiro “Matz” Matsumoto, and he’s speaking to over 500 Ruby developers at the annual two-day Bath Ruby Conference.
The Ruby language celebrated 25 years in February although officially the first release of Ruby, 0.95, was in December 1995. In answer to his own philosophical question, Matz suggests software is born when it is named. In the case of Ruby that was two years earlier on 24 February 1993, hence the big celebration in Tokyo and across social media. Matz says he wanted to name it after a jewel: “Ruby was short, Ruby was beautiful and more expensive, so I named my language Ruby,” he says, joking with his community.
However, Matz wasn’t in the UK for the first time in five years to just eat birthday cake. Ruby may have reached maturity, but there are still questions over whether it can survive another 25 years. Like it’s creator, the Ruby language is very likable and garners passionate followers. It’s syntax, for instance, is very readable but expressive in a terse way and as a dynamic, reflective, object-oriented, general-purpose programming language it’s intuitive and easy to learn. Ruby tries not to restrict those who use it or as Matz is often quoted saying: “Ruby is designed to make programmers happy.”
But not everyone is happy. The popularity of the Ruby language has been bolstered for many years by the success of the Ruby on Rails (RoR) web application framework which dominated the web scene, particularly among startups who wanted something that deal with much of the heavy lifting. That dominant uplift saw Ruby soar to fifth place in the RedMonk Language Rankings in 2012, which uses a combination GitHub and Stack Overflow language rankings to assess a language’s popularity, [since then it’s drifted down to eighth].
But RoR, although popular, isn’t the superstar that it was and It has faced fierce competition as issues such as scaling have become a greater concern for web companies. The JavaScript framework Node.js, for instance, has become popular as it requires less memory to deal with numerous connections because of its callback functions.
It’s clear that Matz is aware that the adoption of any programming language is stimulated by the projects and frameworks that grow from a language’s community and ecosystem – RoR was an astonishing example of that – and not generally from the languages themselves, even if Ruby engenders a lot of love from its users. So while he was keen to express his regret for past mistakes he’d made in his language at the Bath Ruby Conference, he also wanted to define the path forward to address the performance and scale issues that developers have for not using Ruby.
Matz’s approach to addressing the key issues also has an eye to two key trends he sees for the future: scalability and, what he called the, smarter companion.
To combat scalability and create greater productivity, Matz believes, “Faster execution, less code, smaller team [are] the keys for the productivity.”
Computers are getting faster but it’s not enough, “we need faster execution because we need to process more data and more traffic, acknowledges Matz. “We’re reaching the limit of the performance of the cores. That’s why Ruby 3.0 has a goal of being three times faster than Ruby 2.0” or what Matz calls ‘Ruby3x3’. “This is easy to say” Matz admitted and in the days of 1.8, he says Ruby was “too slow” and it was a mistake.
Koichi Sasada’s work on YARV (Yet another Ruby VM) improved performance for Ruby 1.9, and “Since then,” says Matz, “we have been working hard to improve the performance of the virtual machine, but it’s not enough.”
Time for JIT
To improve performance further Ruby is introducing JIT (Just-In-Time) technology, which is already used by JVM and other languages. “So we’ve created a prototype of this JIT compiler so that this year, probably on Christmas Day, Ruby 2.6 will be released,” Matz confirmed.
You can try the initial implementation of the MJIT compiler in the 2.6 preview1. Currently, you can check and compile Ruby programs into native code with the --jit option, but Matz says it’s “not optimised” although for “at least CPU intensive work it runs two times faster than Ruby 2.0,” which he says “sounds promising and offers a lot of room to improve performance of the JIT compiler”. For CPU-intensive tasks, in particular, Matz sounded confident that they would be able to accomplish the three times performance improvement.
According to comments found in the MJIT code by John Hawthorn, the current prototype JIT compiler has quite an unusual approach as it uses C compilers, GCC and LLVM Clang, for the implementation and although Ruby code is single-threaded, MJIT is compiled on a second thread.
Probably the clearest overview explanation of how MJIT works is supplied by Shannon Skipper:
“With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction.
Scalability, Matz also believes, should mean creating less code as “more code is more maintenance, more debugging, more time, less productivity,” and he joked “more nightmare.”
Less Ruby code isn’t going to mean significant changes to the language’s syntax going forward, however. Largely because there is little room for change: “we have run out of characters. Almost all of them are used,” says Matz.
Being an exponent of egoless development, he is also not prepared to change the syntax for the sake of his self-esteem and see existing Ruby programs broken, so he was careful to say: “we’re not going to change Ruby syntax that much.”
Process should be dealt with by smaller teams as well, according to Matz, to handle scalability and increase productivity: “If your team is bigger than the fact they can eat two pizzas,” quoting CEO of Amazon Jeff Bezos’ Two-Pizza Rule “then your team is too big.” Frankly, that may depend on who is on your team and how much they like pizza, but the idea, Matz says, is based on personal experience, “if your team is bigger then you need more communication and communication itself is the cost.”
More abstraction
There have been quite heated debates in recent years about the need for more Ruby abstractions that provide services for developers to build applications suited to different fields, so it was interesting to hear Matz say that Ruby needed “more abstraction”, and mentioning Ruby on Rails use of Model-View-Controller (MVC) abstraction as an example. The Ruby creator didn’t think they were perfect “but they provide the kind of abstraction that is vital for productivity in the future.”
One key abstraction he elaborated on was a concurrent abstraction project called Guild.
“One thing I regret in the design of Ruby was thread [...] it is too primitive,” Matz admits. But Ruby is a victim of its own success: The language is used by so many people, so Matz feels it’s too late to remove thread.
“I think it’s okay to include a new abstraction,” he ventured “and discourage the use of threads” in the future. "Guild is Ruby’s experiment to provide a better approach. Guild is totally isolated,” Matz told the audience in Bath.
“Basically we do not have a shared state between Guilds. That means that we don’t have to worry about state-sharing, so we don’t have to care about the locks or mutual exclusives. Between Guilds we communicate with a channel or queue.”
Matz expects to ship Guild’s concurrent abstraction in Ruby 2.7 or 2.8.
Another code-named project that Ruby has in the works is Steep. This is an attempt at static type analysis for Ruby: “It’s difficult to analyse the Ruby type information, because Ruby is a dynamically typed language, so you can do anything with all types,” explained Matz. Some subsets of Ruby can be statically typed, so Matz says they can add those static-type checks, which are “kind of like a TypeScript user-defined type information [...]. We’re going to infer as much as possible and we’re trying to get the information from those external type-defined files or from the runtime profile type analysis…”
Using this analysis, Matz suggests, developers will be able to detect more errors at compile time, “We’re not going to implement 100% detect safety, it’s not possible for Ruby, but we can detect 20-40% of errors,” which Matz says is far better than nothing at all.
Matsumoto also touched on Ruby becoming a “smarter companion” as well as the programmer’s best friend. “We [are] now at the beginning of smarter computers, so, for instance, RuboCop [static code analyser] is one way of helping you,” although, Matz commented to much laughter in the audience, he’s “not a big fan of the RuboCop default book of rules.” Matz suggested that in the future, when you compile a program “Ruby could suggest [for example] ‘You call this method with an argument string but [did] you expect to call this method with integer’”. Speaking to him after his keynote, Matz elaborated a little more on his hopes for the interactivity of programming, which he agreed they sounded like Tony Stark’s Jarvis. Matz says he essentially wants to see “an AI [that] will interact with me to organise better software.”
Mind the gap
Change brings with it the possibility of software that no longer works as intended or at all. It’s a concern that haunts Matz from past mistakes: “In the past we made a big gap, for example between 1.8 and 1.9,” says Matz. “We made a big gap and introduced many breaking changes, so that our community was divided into two for five years.”
Although this kind of thing has happened in the past, the classic example being with Python 2 and Python 3, Matz sees this as a tragedy: “we’re not going to make that mistake again so we will do a continuous evolution. We’re going to add the JIT compiler to 2.6 and not wait until Ruby 3.0, we ‘re going to add some type of concurrent abstraction in the future in Ruby 2.7 to 2.8, but it will not be a breaking change. [...] We will have it so that every Ruby 2 program will run in Ruby 3.”
Reversing Ruby’s current slow trajectory downwards is not going to be an easy task and Matz seems to realise this. Commenting on seeing the recent Stack Overflow Developer Survey results on the morning of the keynote his smile disappeared briefly: “Go and Rust are the most loved languages and Ruby is not in the list, unfortunately. I believe that Ruby will become hot again in the future. People love new technologies. Ten years ago Ruby was really hot, because of Rails. These days Ruby isn’t considered hot, but it is stable.“
Ruby, however, has crossed that gap into maturity and Matz has no intention of giving up: “Ruby is a good language to help to you become productive and I want Ruby to be like that for forever, if possible. That means we have to evolve continuously forever, so we can’t stop; we can’t stop”
Part of that momentum is reflected in the first ever Ruby Hack Challenge held outside of Japan. This took place last week at the new international headquarters of Cookpad, a recipe-sharing platform that employs Ruby developers extensively, in Bristol. These challenges are an opportunity for aspiring committers to learn how to extend Ruby features, fix bugs, and improve the performance of Ruby.
According to Miles Woodroffe, CTO of Cookpad, the main sponsor of the Bath Ruby conference, this hack was focused on the Ruby Interpreter which instructs computers how to run programs written in Ruby code.
One of the goals of the hack allowed participants to directly contribute to the next version of the Ruby Interpreter.
As the release of Ruby 3 draws closer, slated unofficially for 2020, it’s clear that Matz wants to continue providing a tool that helps you concentrate on the fun and enjoyable aspects of programming.
Two things are apparent when talking to Yukihiro “Matz” Matsumoto. First, that he will do anything he can to enable Ruby to survive and thrive and, second, that he’s thoroughly enjoying himself doing what he does. He’s passionate about Ruby and its community and his outlook is quite simple: Programming is fun, he’s had fun for the last 25 years making Ruby and at the age of 52 now, he hopes that he’ll get to spend the next 25 years having as much fun working on the language he dreamt up and wrote down in – a now lost – notebook, at the age of 17.
- This is an extract from an article for the monthly Linux User and Developer magazine, the respected authority on GNU/Linux and the free and open source ecosystem for Linux enthusiasts, IT professionals and developers. Subscribe today and get 5 issues for £5 (UK only. Offer ends 30 April 2018).
