00:00:00.880
Let's start with our amazing Mats. Our opening keynote speaker is Yukihiro Matsumoto, also known as Matz, who is a Japanese computer scientist and software programmer. He is best known as the chief designer of the Ruby programming language and its reference implementation, Matz's Ruby interpreter. His demeanor has inspired a motto in the Ruby community: 'Matz is nice, and so we are nice,' commonly abbreviated as 'M.A.N.' As of 2011, Matsumoto is the chief architect of Ruby at Heroku, an online cloud platform as a service in San Francisco. He is also a fellow at the Rakuten Institute of Technology, a research and development organization within Rakuten, Inc. Furthermore, he was appointed technical advisor for Vassily Inc. starting in June 2014. So many difficult words in English—I'm trying my best! But let's give the floor to Matz. Please welcome him.
00:01:34.000
Hello, this is Matz, the creator of the Ruby language. Today, I'm going to talk about Ruby 3 and beyond. Ruby 3 was finally released on December 25th, 2020, last Christmas. We have significantly improved the language since its major release. Ruby 3 is now more concurrent, more performant, and more productive. For concurrency, we added Ractor, which is the Ruby version of the actor model. For performance, we introduced the JIT compiler and improved the garbage collector to make it more efficient. Additionally, we added new tools like 'Stead' to support static typing, specifically with tools named RBS and TypeProf.
00:02:43.120
The three major goals of Ruby's 3.0 release were to ensure compatibility, improve speed, and enhance quality. Let me explain them one by one. First, for compatibility, almost all 2.x programs run on 3.0. Therefore, we have taken great care to ensure compatibility so that you don’t need to modify or upgrade your application to migrate to 3.0. Compatibility matters very much.
00:03:31.360
We learned our lessons from the Ruby 1.9 tragedy. Ruby 1.9 was introduced in 2007, and that version featured some incompatibilities. For example, we added encoding features to better support Unicode, which changed the behavior of the String class heavily. Consequently, many applications had to be upgraded to migrate from Ruby 1.8 to 1.9. Some community members stayed on the older version for a long time, causing a community split that lasted more than five years. A similar situation occurred in other languages as well. Python 3 introduced incompatibilities with Python 2, leading some users to remain on the older version.
00:05:01.440
PHP 6 faced drastic changes which resulted in the community refusing to migrate to the newer version. As a result, the PHP 6 project was cancelled, and they started over from PHP 5, leading to PHP 7. The same sort of situation happened with JavaScript; ECMAScript 4 was a challenging upgrade, and eventually, the project was cancelled. Some features that were part of ECMAScript 4 were reintroduced in ECMAScript 6. Thus, incompatible changes are often unacceptable for the community.
00:06:58.560
This situation has its reasons. Language designers like us make mistakes. In the past, we have made many errors, and if possible, we want to correct those. We strive to create a better programming language—simpler, more consistent, and more intuitive. Maintaining compatibility is crucial, especially during major version upgrades. As seen with Python 3, PHP 6, and ECMAScript 4, significant upgrades can sometimes break existing code and create pain for users.
00:09:18.480
Despite this, humans can accept minor changes in applications—like altering button colors or positions—much more easily than changes in a programming language that can disrupt functionality. This contradiction exists because while programmers enjoy the challenge of new technologies, they want to avoid the pain that comes from forced adaptations to new features. Hence, we prioritize maintaining compatibility for Ruby 3.
00:10:49.040
In terms of performance, we have enhanced Ruby significantly, introducing the Just-In-Time (JIT) compiler which dynamically generates native code. The JIT compiler, named MJ, has sped up Ruby since version 2.6, with goals for Ruby 3.0 including achieving a three times speed increase in certain benchmarks. One such benchmark, called 'optcarrot,' measures CPU-intensive tasks using old Nintendo games, counting frames per second.
00:12:47.840
Ruby 3.0 has made many rare applications run faster. In fact, at the time JIT was first introduced in Ruby 2.6, many applications ran slower with it, but over the last two years, we have improved performance significantly. Now, popular frameworks like Sinatra run just as efficiently with JIT as without it. For concurrency, we recognized that back in 1993, most computers had only one core. Therefore, Ruby was originally designed for concurrency without parallelism, so performance was not a goal back then. However, trends have changed, with many modern machines having multiple cores, and thus concurrency is now essential for performance.
00:21:40.000
In order to enhance Ruby's concurrency model, we added a feature called Ractor, which allows parallel execution of Ruby programs without the Global Interpreter Lock (GIL) hindering performance. Ractor allows creating isolated execution environments, where each instance of Ractor can run on separate threads without needing to access shared state, allowing better use of multi-core processors. Additionally, we introduced the idea of fibers for non-blocking I/O operations, allowing for more efficient use of resources during I/O-heavy tasks.
00:23:28.880
Ruby 3.0 also includes improvements in error handling and aims at adopting static typing techniques. Amidst the rise of programming languages favoring static typing, such as Go and Rust, we have made moves toward static typing without altering the syntax of Ruby. This involves introducing tools like RBS, which allows describing the types used in Ruby libraries and applications without imposing strict typing on the language itself. Additionally, we introduced TypeProf, a tool to perform naive type checks and generate RBS signatures for Ruby applications.
00:29:01.440
While there are still challenges in extracting generic types or interfaces, RBS allows developers to enhance their applications' static type information effectively. We also introduced pattern matching and numbered parameters as new syntactic features in Ruby 3. These allow for cleaner and more effective coding practices. Pattern matching enables developers to retrieve and check elements within complex data structures effortlessly. This adds a layer of expressiveness and effectiveness when dealing with Ruby's flexibility.
00:51:59.680
Over the years, we have aimed to enhance Ruby, aiming to create a better world for developers. We want Ruby programmers to enjoy programming and work towards a brighter future. Our gift to the world is a commitment to making Ruby language better. I encourage you to join us in this mission to create a better world through programming, enjoy the Ruby community, and develop thoughtful solutions.
00:54:43.599
Thank you for your time, and thanks to the sponsors of this event for making it possible. If you arrived a little late, the stream chat can be found on the left side of the navigation—please click to open it and engage in our discussions. I’d like to share that we have received several questions and comments from the chat, which significantly contributes to our community. Now, let’s dive into the questions, starting with Matz's thoughts on whether the incompatibilities from version 1.9 were a mistake, considering how the community fondly came back together after the split.
