00:00:04.860
Hello there! I am Matz, the creator of the Ruby language and the keynote speaker for this conference.
00:00:12.960
The pandemic has had several side effects. One of them is that I have had fewer opportunities to speak in English. I have never had a chance to visit other countries like Europe or the United States, which means my ability to communicate in English is getting worse.
00:00:32.340
Over the next 45 minutes, I will do my best to give you a coherent explanation in English. However, I ask for your understanding as I navigate this.
00:00:49.920
This year, I am going to talk about "Mythbusters". But before that, let me share a little about the kind people I have encountered on the internet over my 20 years of online experience. There are so many kind people out there, and I feel incredibly grateful for their support.
00:01:17.820
At the very early stages of developing Ruby, I received an email that claimed Ruby is too good to be a scripting language. The person argued that scripting languages are typically for scripts less than 100 lines long and therefore Ruby shouldn't be categorized as one.
00:01:30.900
But in reality, the power and goodness of Ruby as a programming language allows us to be happy and productive. It can hardly be considered too good to be either a programming or scripting language.
00:01:50.360
Around the same time, I received an email claiming scripting languages do not need object-oriented programming. Back then, many popular scripting languages were not object-oriented. For example, Perl was still in version 4 and not object-oriented. Python, on the other hand, was a newcomer with its object-oriented capabilities, but it was less popular at that time.
00:02:12.239
The sender believed that scripting languages did not require the complexities of object-oriented programming. However, I think we have proved him wrong.
00:02:31.080
Before Ruby on Rails, there were struggles to find a killer application for the Ruby language. Many people told me nobody used Ruby, opting instead for Perl, PHP, Python, and other languages.
00:02:54.720
They insisted that there was no standout application for Ruby. Some even said I shouldn’t have created Ruby and suggested focusing on established languages like Perl for the sake of humanity.
00:03:12.600
They believed that if we concentrated our efforts on existing languages, we could have better programming languages that serve human beings well.
00:03:30.960
Others have claimed that Ruby is slow and that in the age of web pages and AI, Ruby is losing its relevance. People say Ruby is dead or that other languages like Rust or Go have overshadowed it.
00:03:53.040
What irritates me is not the negative comments about Ruby, but rather the unfairness of those comments. In Japan, we have a proverb about a fox borrowing the authority of a tiger.
00:04:11.400
When someone compares languages like Ruby to others backed by well-known creators, such as Guido with Python or Larry Wall with Perl, I appreciate the discussions. We can analyze what each language does well and where they fall short, exchanging ideas to develop better programming languages.
00:04:31.080
However, many of the critiques come from those who don't truly engage with the language. They act as third parties, simply trying to provoke a reaction, which is not constructive.
00:04:47.040
The point is that we must seek out real value. And I found that the most significant values related to Ruby are about community, joy, and productivity—all of which intriguingly end with a 'y'.
00:05:05.040
As an example, this is a list of top Ruby companies created by a friend of mine, showcased by their total market cap value. Companies like Airbnb, Shopify, Square, and Coinbase are valued in the tens of billions, all developed using Ruby.
00:05:27.000
These companies are creating substantial market value through Ruby, proving there is concrete success tied to this language.
00:05:49.560
Another list shows 50 software companies sponsored by Y Combinator. They represent a mix of technologies, with 13 out of those 50 utilizing Ruby, contributing to a staggering market valuation of 52% from Ruby companies.
00:06:06.300
This data is compelling and serves as evidence that we can disregard the negative noise from the internet. As long as we continue to create value, we can move forward.
00:06:23.040
I believe the essence of Ruby lies in its development velocity. This productivity is another area that emphasizes the language's strengths.
00:06:41.220
Productivity enables us to finish tasks quickly. If we can solve these tasks efficiently, this is tangible value—quick solutions that address various challenges.
00:06:59.040
Although Ruby is not the top-performing language today, I acknowledge that its popularity fluctuates. We should not sway with every trend.
00:07:14.040
In the 2010s and 2020s, static typing became the trendy preference, with languages like Rust, Go, Kotlin, and Swift rising in popularity. Even Python and PHP have embraced type annotations.
00:07:32.280
However, in the 1990s and 2000s, languages like Ruby and Python, with their dynamic typing, were thriving and considered innovative.
00:07:51.240
Today, JavaScript has type annotations with TypeScript, and PHP has type declarations. The question arises: should Ruby integrate type annotations into its framework?
00:08:05.160
I don't believe so. Many misunderstandings surround static typing. For one, static typing isn't new; it predates dynamic typing.
00:08:23.520
Static typing has its benefits, such as catching errors at compile time and acting as useful documentation. Languages with strong type inference have a robust way of managing these.
00:08:42.960
However, relying solely on type declarations can lead to complications with software development, as it's fundamental that documentation remains up-to-date and consistent.
00:09:00.720
Using type definitions as part of a program implies accuracy while relying on external documentation can lead to inconsistencies. Moreover, type information aids compilers in optimization.
00:09:24.600
Yet, static typing can be detrimental. As a community, we've experienced writing software with type annotations, leading to redundancies that contradict Ruby’s principles.
00:09:36.959
Some type definitions can be needlessly complex. As proven in various studies, writing down algorithms in type declarations can often be unnecessarily convoluted.
00:09:51.240
For instance, I recently saw a video demonstrating tic-tac-toe implemented in type declarations. Such complexity raises concerns about the maintainability of type declarations in Ruby.
00:10:06.480
There are worries that adopting such a structure could create friction in the Ruby community, leading to an atmosphere where library authors feel pressured to implement type declarations.
00:10:21.960
So while we recognize that static typing has its benefits, the need for rigid type definitions is less clear. We want to introduce a concept called RBS—Ruby signatures.
00:10:32.640
This means we can achieve some of the static typing benefits without the annoying necessity of type annotations. We're also working on tools to support these transitions.
00:10:48.840
Types Prof uses abstract interpretation to generate prototype signatures for applications and I hope this will improve the development experience.
00:11:05.520
Furthermore, we are creating the steep—a signature-based analyzer that will help you discover type errors. This tool will enhance your experience by improving IDE support.
00:11:22.799
The Ruby community is committed to improving productivity through better tools and continued enhancements in Ruby’s performance.
00:11:37.160
We’ve kept moving forward for nearly 20 years now, investing in Ruby to create a better development experience.
00:11:56.640
I invite you all to join us in this endeavor to enhance developer productivity.
00:12:05.200
This talk is sponsored by Salesforce.com and many other contributors from the Ruby community. I appreciate everyone's support, and I really wish to see you in person at the next conference.
00:12:29.359
Thank you!
00:12:57.380
Hi, Matz!
00:13:20.640
The first question is from Luciano. What do you think about Sorbet and the other community initiatives surrounding type checking?
00:13:35.160
The core community is primarily investing in RBS—the Ruby signature system—and Steep, as we are unlikely to introduce type annotations in any capacity in the future.
00:13:52.080
Currently, Sorbet is more performant and complete than RBS; however, for those looking towards the future of Ruby, we encourage them to explore the Ruby signature system.
00:14:09.600
The next question is personal. Are there any features you regret introducing to Ruby? Do you have 'big regrets'?
00:14:23.400
I have borrowed some features from Perl, particularly cryptic global variables, which I regret. Additionally, I regret adding threads to the language early on.
00:14:36.420
At the time, most computers had only one CPU, and we focused on the descriptiveness of algorithms. Today, concurrent programming and leveraging multiple CPU cores is the norm.
00:14:58.920
I believe if we had provided something like Ractor for concurrency at the start, it would have significantly eased concurrent programming in Ruby.
00:15:14.279
The next question touches on longevity. How can developers support Ruby to ensure its survival for the next 100 years?
00:15:27.720
It's quite a challenge to predict the future, even five years ahead, let alone a century. Ruby began as a personal hobby, and it's now a community effort.
00:15:43.560
Organizing our efforts and gathering strength from the community will be essential for Ruby's survival in the long term.
00:15:59.240
Another question from Luciano: Apart from type checking, which areas do you see Ruby needing improvement?
00:16:15.660
I believe Ruby should enhance its interaction capabilities with developers, particularly through IDEs. Supporting tools like VS Code can greatly boost productivity.
00:16:33.600
With advancements in tooling, even without type declarations, Ruby can benefit from inferred typing within expressions, leading to superior code completion.
00:16:49.440
Next, we have a question from Vesa Vanska about encouraging Ruby library authors to provide RBS types.
00:17:07.920
We are actively working on a gem RBS collection that serves as a counterpart to the DefinitelyTyped repository of TypeScript, making it easier for library authors to adopt Ruby signatures.
00:17:19.560
Christian's question involves what aspect of Ruby you currently enjoy working on. What is your favorite feature?
00:17:37.800
I take great pride in having invented blocks in Ruby; it's one of the greatest innovations in the language.
00:17:46.080
If Ruby didn’t exist, what language would you pick? I really like Julia for its unique aspects, but I also have an affinity for Lisp languages.
00:18:01.560
Simon inquires about contributions to open source projects and how to stay positive after years of coding. What is your opinion?
00:18:19.080
I think evolving through open source activities greatly boosts the joy of programming. Writing software for customers can be challenging, but working on open source is incredibly fulfilling.
00:18:34.260
There's a question about Visual Studio's debugging capabilities. How long until Ruby catches up, and how can developers help speed this process?
00:18:49.200
I'm not directly involved with VS Code activities but writing a VS Code plugin isn't too complex. If you possess the knowledge, you can contribute to the open-source community.
00:19:08.760
Finally, could you share what we can expect from Ruby in the future?
00:19:27.480
I foresee several things including consistent improvements to performance through advancements in compilers and memory management.
00:19:47.640
Ruby 3.0 aimed for a significant performance increase over its predecessors, and future updates will focus on enhancing both performance and productivity.
00:20:07.200
Combining these improvements will create enjoyable programming experiences, highlighting the joy of Ruby as a core value.
00:20:24.240
Thank you, Matz, for attending and sharing your insights.
