Opening Keynote by Yukihiro 'Matz' Matsumoto

by Yukihiro "Matz" Matsumoto

In the opening keynote for RubyConf 2016, Yukihiro 'Matz' Matsumoto reflected on the origins and growth of the Ruby programming language while discussing its future direction and community. He shared his journey from the initial creation of Ruby in 1993 as a personal project, driven by his passion for programming languages, to the emergence of a flourishing global community of approximately one million Ruby users today.

Key Points Discussed:

Origin and Growth of Ruby:
- Matz began learning programming in 1993 and developed Ruby, aiming to create a language distinct from others like Lisp and Perl. Ruby's first public release occurred in 1995, which unexpectedly garnered a large community interest.
- The first RubyConf in 2001 had just 30 attendees, while RubyConf 2016 hosted around 650 participants, showcasing the significant growth of the Ruby user base.
Understanding Open Source Community:
- Matz discussed the nature of the Ruby community as inclusive and non-exclusive, stressing the importance of continually attracting new members for sustainability.
Challenges in Language Evolution:
- Addressing concerns about Ruby’s relevance, Matz acknowledged challenges due to changing technological landscapes and the importance of continuously adapting Ruby while maintaining community compatibility.
- He shared insights on the need for gradual, thoughtful changes to avoid alienating users and emphasized the lessons learned from other programming languages' struggles.
Future of Ruby Language:
- Matz proposed rebuilding parts of Ruby to enhance features like multi-threading and introduced a new concurrency model called Guild to improve concurrent programming without sacrificing compatibility.
- The introduction of static type features through 'dark inference' aims to retain Ruby's dynamic nature while enhancing error detection and documentation practices.
Community Engagement and Collaboration:
- Matz concluded with a call to action, urging all community members to contribute towards improving Ruby and embracing the goals set for Ruby 3, including enhanced concurrency and performance improvements.
- He highlighted recent updates in Ruby 2.4 that promote simplification and efficiency in the language.
Final Remarks:
- Matz expressed hope for a bright future for Ruby and shared a lighthearted moment featuring his dog, reinforcing the importance of community connection.

Conclusion:

Matz's keynote underscored the significance of compatibility and gradual progress in language design, encouraging collaboration within the Ruby community to navigate the challenges of evolving technologies, maintaining user experience, and ensuring the language's longevity. He emphasized the core values of kindness and cooperation as essential to Ruby's ongoing success and development.

00:00:16.000 Good morning, everyone! Good morning! You might notice some conflicting feelings inside of me. I'm so happy to see your smiling faces. I'm very excited to have traveled all the way to Cincinnati, but as a programmer, I hate speaking before an audience. Nevertheless, I hope I can share something helpful with you.

00:01:12.479 Let me take you back to 1993. I started learning programming and developing Ruby just for fun. I’ve always been a language geek, loving programming languages like Lisp, Smalltalk, C, Pascal, and C++. Back then, we didn’t have PHP, so I created Ruby as a pet project. To my surprise, once I released Ruby, people found it and began to love it.

00:02:01.240 In 1995, I posted the first version of Ruby, version 0.995, on the internet. It was way beyond my expectations. Soon after, I created a mailing list, and within a week or two, we had 200 members. I never anticipated this attention; there are tons of programming languages, many of which are just toys. Ruby was initially seen like that, but gradually it became more significant.

00:02:41.000 Many programming languages, toys at first, eventually disappeared from the internet because people grew tired of them. I thought creating a new programming language would be fun. Additionally, I learned a lot from free software, particularly by studying the source code of Emacs, which inspired my return to the community with Ruby.

00:03:23.720 By the year 2000, I was astonished when the famous Dave Thomas wrote a book on Ruby, which sold around 20,000 copies. I assumed that maybe half of that number, roughly 10,000, were Ruby users. This led to the first RubyConf in 2001 in Tampa, Florida, which surprisingly had 30 attendees.

00:04:56.680 Fast forward to this year, RubyConf in Cincinnati had about 650 participants. A few years ago, someone even mentioned we could reach a million Ruby users one day. So here we are, possibly having around one million Ruby users worldwide, which is a remarkable community growth.

00:05:50.720 Now, what does it mean to be part of an open-source community? A community is not a formal organization. You don’t need to pay membership fees or go through initiation rites to be part of the Ruby community. You feel that you are a member of the community when you identify with it, and you can just as easily identify with other programming communities.

00:06:53.159 Being a member of the Ruby community doesn’t restrict you from using other languages. However, this non-exclusivity means we cannot expect strong loyalty from our community members. It can fluctuate, and if someone becomes dissatisfied, they might leave. As a result, we need to continually attract new community members to ensure our survival.

00:08:07.640 I often think that the open-source community is like a shark; it needs to keep swimming to survive. Recent discussions about Ruby being 'dead' due to fewer GitHub stars or changes in technologies can be disheartening. No technology can stay shiny forever. Ruby has existed for over 20 years, and Rails for more than 10 years. We face more challenges to maintain relevance, and so we need to evolve.

00:09:17.320 What can we do? One solution is to rebuild the language. Other programming communities, like PHP, experienced a similar path. They tried to advance to PHP 6 but failed. Eventually, they succeeded with PHP 7. Other languages like ECMAScript went through trials with version 4 but couldn't achieve their goals of improvement.

00:09:50.040 Though those setbacks didn’t hinder their success overall, it serves as a lesson. It's important to avoid drastic changes when trying to improve a programming language. We have our own instances where we made significant changes, like the transition from Ruby 1.8 to 1.9, which resulted in a long migration period and a considerable compatibility gap.

00:10:30.600 In my journey as a designer of Ruby, I learned the valuable lesson that we shouldn’t just strive to continuously improve the language; we need to understand that Ruby is not the first or the most powerful language. We utilize Ruby for its simplicity and the comfort it brings to our programming experience.

00:11:15.440 The essence of Ruby lies in its human-centric design. There are principles we should uphold: first of which is the importance of compatibility. Maintaining compatibility isn’t rooted in fear of change; it’s about enabling progress within the community. If we provide compatibility, more users will adopt newer versions of the language.

00:12:00.360 The community can only move forward if users embrace updates. As language designers, we want the programming language we create to flourish; however, making significant changes can lead to user discomfort, which feels selfish. I became aware that our aim isn't just to fulfill our desires but to consider users and potential users alike.

00:12:50.200 To construct a better design model, we must base our decisions on the constraints and considerations of keeping compatibility. Similar to a speedrun challenge in a video game, implementing these constraints can be difficult yet rewarding. Our goal should be to enhance the user experience while fostering the language's development.

00:13:38.200 In terms of compatibility, we must also acknowledge the current state of Ruby’s multi-threading feature, as it comes with its own complications, such as deadlocks and race conditions. In the early days, we assumed that threading would simply be a beneficial programming model, but we now recognize the challenges of effective concurrency.

00:14:29.560 Today, with the rise of multi-core processors, real threading leads to significant issues. I regret implementing threads initially, recognizing that they can easily cause problems. However, I can’t just eliminate this feature; our community relies on it. To enhance the threading model, we are considering a new concurrency model, which I will discuss in our sessions tomorrow.

00:16:12.520 The new model, called Guild, focuses on creating a membership structure among objects that would allow for more effective concurrent programming without sharing objects across guilds. While within a guild, the ability to use threads remains, thus bringing reliable parallelism to Ruby while striving to maintain compatibility.

00:17:10.560 In this decade, many static type programming languages have become popular, yet they come with their own trade-offs. While TypeScript, Flow, Go, and Swift have moved towards including explicit static types and type decorations, they often reduce flexibility and lead to increased code verbosity.

00:18:15.200 Ruby is well known for its exceptional duck typing, where things just work without the constraints of explicit type declarations. We often joke about our duck typing philosophy; if it walks like a duck and quacks like a duck, we assume it’s a duck.

00:19:01.440 However, there’s an argument to be made for the benefits of adding static type features that allow for earlier error detection and better documentation practices. This is where the idea of type inference comes into play, allowing us to omit boilerplate declarations without sacrificing the ease of use or the spirit of Ruby.

00:19:59.919 I envision a system of 'dark inference,' where types would be inferred based on behavior, rather than defined explicitly, allowing programmers to focus on functionality rather than types. This will be an avenue for flexibility without impacting the legibility or usability of the Ruby language.

00:21:01.920 For instance, a method can be designed to work with any object as long as it responds to a particular method, rather than enforcing artificial constraints based on class inheritance. Dynamic language constructs the basis, making the programming tasks at hand less laborious by focusing on what an object does rather than what it theoretically is.

00:22:10.560 While progressing nearer towards these ideals, we can still incorporate static type analysis where it benefits users, especially when working with tests. There might come a time where our understanding of these programming paradigms will lead us to communicate more effectively with machines, potentially reducing friction in development.

00:23:01.879 As we move forward, we must think critically about the future where languages become concise. The need for less code and better communication between humans and machines remains imperative. I truly believe we can eliminate unnecessary redundancy within Ruby and optimize the developer experience without compromising the rich Ruby culture.

00:23:44.959 Through ongoing reviews of our approach, there will be chances to bring Ruby programming to the next level. I urge all aspects of the community—from gem developers to application creators—to collaborate, and innovate, leading us to efficiencies and simplicity that enhance how we use Ruby.

00:25:21.600 In summary, our collective principle is to be nice. By being nice, we can become stronger. Being nice means embracing gradual change, improving collectively while maintaining compatibility. We want to move forward together, creating an environment where Ruby can flourish—all while ensuring that everyone benefits.

00:26:47.680 Moreover, we should encourage advancements, like the features coming in Ruby 3, which embody our goals. These goals are challenging, and they might seem near impossible, but they’re imperative to push us further. Our goal to add new concurrency model features or improve type analysis illustrates our commitment to progress.

00:27:56.960 From updating the interpreter to enhancing documentation accessibility, the journey toward a better Ruby is ongoing. We need contributions, tools, and frameworks to bring about this transformation, ensuring we never get complacent and always strive for improvement in our Ruby ecosystem.

00:29:18.760 Everything we are doing is to ensure that Ruby continues to serve its purpose effectively and gracefully. Additionally, I would like to mention some recent updates regarding Ruby 2.4 that includes various performance improvements, such as faster hash handling, which originated through contributions from dedicated developers.

00:30:57.440 This removal of classifications for integer data types showcases our efforts for the sake of simplification in Ruby. We are also refining Unicode case mapping so it now behaves as expected not only for ASCII characters but also accents and special cases.

00:31:58.160 Finally, we aim to release Ruby 2.4 this December with these improvements. I truly hope for a bright future ahead for Ruby, and I sincerely thank you all for being here. And just to end on a lighter note, I’d like to share a picture of my dog to ensure he doesn’t feel overlooked due to my fondness for my cat.