Ruby
Opening Keynote: Good Change, Bad Change
Summarized using AI
Opening Keynote: Good Change, Bad Change
by Yukihiro "Matz" MatsumotoThe video features the opening keynote titled "Good Change, Bad Change" delivered by Yukihiro "Matz" Matsumoto during RubyConf 2017. In his address, Matz reflects on the evolution and community dynamics of the Ruby programming language, which he created in 1993. He expresses his gratitude towards the community and addresses concerns about language changes.
Key points discussed include:
- Community and Change: Matz emphasizes the importance of the Ruby community, noting that while some developers have moved on to other languages, many continue to embrace Ruby. He acknowledges the challenges and frustrations that come with implementing changes, particularly those that break existing compatibility.
- Language Evolution: Matz reflects on the maturity of Ruby, discussing its history, including significant versions like Ruby 1.8 and 1.9, and the upcoming Ruby 3, which aims to improve performance significantly. He shares concerns about maintaining backward compatibility while encouraging innovation.
- Good vs. Bad Changes: Matz delineates between 'good changes' that enhance user satisfaction and productivity and 'bad changes' that create additional burdens for users. He asserts the necessity for thoughtful design choices that prioritize user experience over the satisfaction of the designer.
- Performance Goals: Matz shares aspirations for Ruby's performance, seeking improvements year after year while maintaining its simplicity and usability. The targets for Ruby 3 include being three times faster than Ruby 2.
- Future Directions: Looking forward, Matz emphasizes the need for clear communication and community feedback to guide Ruby's trajectory. He highlights various recent improvements in performance, usability, and community inclusivity, such as support for Unicode 10.
In conclusion, Matz advocates for embracing necessary changes while minimizing adverse effects on the community. He believes that with collaborative input and a focus on enhancing the user experience, Ruby can continue to thrive as a beloved programming language. Matz wraps up his keynote by inviting the community to contribute their Ruby memories as they celebrate Ruby's 25th anniversary.
00:00:11.060
Hello everyone! Oh hello! AHA, this is Matz. It’s great to see you!
00:00:24.320
I would like to ask you some questions, first.
00:00:33.870
Thank you! Welcome to RubyConf.
00:00:40.399
These are the first seekers.
00:00:45.930
No, really, I'm updated.
00:00:51.930
Okay, I'll tell you. We're here to recount this as always.
00:00:57.199
I have to stop this mess. I’m a little bit concerned about giving a keynote presentation in English.
00:01:06.900
So, I wish everyone could speak, but still, those who came before us did an amazing job.
00:01:24.079
Yes, there are some coined phrases like...
00:01:30.600
A meaningless one that's doubtful, but it's nice.
00:01:39.930
And so, we are nice. And then we have discount stickers on some laptops.
00:01:45.420
I actually like this phrase because it sounds like a Nina song in Japanese which means able.
00:01:52.890
So, there are terms focused on inclusive attitudes within the community.
00:01:59.700
That's quite a nice phrase and impressive for me.
00:02:07.350
I know I’m not really a nice person inside.
00:02:13.660
So, because the phrase about being nice is quite embarrassing to me, I'm kind of stuck.
00:02:21.300
You know, I came up with the idea of reform, which came to mind.
00:02:31.120
Ruby is nice to be nice here. It is a place that tries to be nice to you.
00:02:38.200
It's a You-know-generated shell, so it is a nice place. Unless you locate the source code.
00:02:51.460
But, yeah, this year we don’t need excuses. So, be nice.
00:03:01.360
Yeah, shake hands with everyone you can, and with the next person too.
00:03:12.709
Be nice. Being nice makes you proud.
00:03:21.700
Very nice, very nice try!
00:03:28.030
Keeping the advice of the community does well for redesigns.
00:03:37.260
We are no longer the new kids on the corner.
00:03:43.270
We have grown older; Ruby was born in 1993.
00:03:56.130
This echoes the definition of the first day of the language.
00:04:01.450
For software, it's quite important that a name is significant.
00:04:08.890
Software is a virtual entity so a name is the only thing we can grab.
00:04:15.550
Hence, I named my language Ruby.
00:04:23.230
February 24th, 1993, Wednesday. So, it turned 25 this year.
00:04:38.830
That means Ruby has grown older.
00:04:50.470
Java projects started in 1993, and Java was released to the public in 1995.
00:04:57.850
Ruby was a leap project that was also started in 1993.
00:05:04.120
Ruby was released to the public on December 21, 1995.
00:05:11.320
So Ruby is as old as Java.
00:05:18.910
Recently, new languages emerged, like Swift, Go, Elixir, and many more.
00:05:24.790
Some people try new languages or even move on.
00:05:32.830
Some claim that Ruby is dead.
00:05:40.340
I used to believe that, but I see so many people here—millions of people still using Ruby.
00:05:51.350
They’re writing numerous applications all over the world.
00:06:02.300
I've attended some conferences that had over a thousand attendees.
00:06:10.340
This one is quite big, with around six to eight hundred people here.
00:06:15.410
It is fantastic, and Ruby is still alive.
00:06:22.690
However, if we make significant changes that break your software, people might scream.
00:06:36.800
Language designers often make mistakes. No one is perfect.
00:06:48.740
We've tried to fix those mistakes in the past.
00:06:56.810
Many languages have made incompatible changes.
00:07:02.560
Ruby 1.x had a huge gap between 1.8 and 1.9.
00:07:07.730
I don’t regret that decision, but it did create a division.
00:07:21.950
Ruby 3 has a compatibility gap; it can sometimes cause huge issues.
00:07:28.370
The community has supported us, but some developers create patches.
00:07:34.010
We've tried to create better languages, but drastic changes can lead to cancellation.
00:07:41.210
For example, the project KGS was canceled due to a lack of community support.
00:07:49.130
We don’t have 56; it was canceled, but 57 remains with gradual changes.
00:08:03.960
That’s how the development has gone, taking years to get there.
00:08:12.210
This is sometimes called the second system syndrome.
00:08:17.700
We are not perfect. We have made mistakes.
00:08:24.780
We want to eliminate these mistakes, reduce technical debt.
00:08:31.800
At some point, we got mad and wanted to throw everything away.
00:08:37.010
However, only a few second systems succeed.
00:08:42.450
The very few succeed due to deep problems that put burdens on users.
00:08:47.850
Ruby should be stable. Ruby is mature. Ruby has grown up.
00:08:55.290
To maintain compatibility is vital to avoid migration costs.
00:09:00.959
Old users are causing community divisions.
00:09:05.140
We had compatibility problems with Ruby 1.8.
00:09:09.840
Some also boycotted the new version.
00:09:15.100
It was tough; I was shocked.
00:09:21.920
I put my effort into creating Ruby 1.3, which was a good version.
00:09:28.390
But still, the community refused to adopt the new version.
00:09:34.450
Some projects were canceled; people left the community for new languages.
00:09:41.740
The open-source community is real; it's a group of people.
00:09:48.210
There's no membership initiation in the Ruby community.
00:09:54.040
It's non-exclusive; you can use Ruby alongside JavaScript or other languages.
00:10:02.630
The membership is non-exclusive, meaning we can't expect strong loyalty.
00:10:10.420
In fact, the Ruby community does show loyalty, but we can't force them to stay.
00:10:16.680
If something happens or if some new technology looks attractive, people will leave.
00:10:23.080
It’s a reality we cannot stop.
00:10:31.550
So we need to attract the community.
00:10:38.930
We must recognize that making breaking changes may push our members away.
00:10:49.920
It's quite difficult to keep our community active amid these changes.
00:10:56.730
If we maintain compatibility, it can be boring.
00:11:06.570
You will lose interest in migrating technologies.
00:11:13.490
It's a contradiction; we want our community active and growing.
00:11:20.740
But to keep them engaged while also maintaining stability is a challenge.
00:11:27.690
If we keep things stagnant and filthy, people will leave.
00:11:31.830
If we initiate progress, breaking changes will upset people.
00:11:38.160
No matter what we do, some people will leave.
00:11:45.800
So the problem lies in managing changes.
00:11:51.400
We like changes, but at the same time, we dislike them.
00:12:04.590
So we have to manage it.
00:12:11.080
There are good changes and bad changes; bad changes bring frustration.
00:12:21.680
For example, changes that make you work harder are often viewed negatively.
00:12:27.360
If you don't want to work but are forced to, it leads to upset.
00:12:36.360
On the other hand, changes that spark joy and excitement in your workflow are good.
00:12:41.840
Good changes enhance performance and productivity.
00:12:52.660
A clean language is not a dead language for me, but it is for you.
00:13:00.480
You may not care about Ruby being a clean language.
00:13:07.760
Making a language simpler can lead to self-destruction from the designer's perspective.
00:13:16.160
So, we must forget about self-satisfaction and avoid bad changes.
00:13:24.760
This is an important design principle to apply to software.
00:13:32.960
Let’s move our focus towards satisfying users.
00:13:41.040
Good performance can be considered a good change.
00:13:47.650
No one can complain about enhancing performance.
00:13:55.010
I never considered Ruby as primarily a first language.
00:14:03.110
I focused on making it enjoyable, satisfactory for users.
00:14:10.340
My goal is to push the programmer's burden to computers, enabling humans to work less.
00:14:19.250
In that sense, language must be less efficient because it has to do more things.
00:14:25.870
Ruby is intentionally slower than other languages like Java or C++.
00:14:32.900
But we focus on making Ruby faster.
00:14:39.600
Every year, Ruby gains speed; on average, 5 to 10% faster.
00:14:46.180
We aim to double this year.
00:14:50.920
Ruby's improvement has been consistent and measurable.
00:14:56.790
Two years ago, in this keynote, I presented the phrase: Ruby 3 by 3.
00:15:02.360
Meaning Ruby will be three times faster than Ruby 2.
00:15:09.310
At that time, it felt like a dream and I didn’t even believe it would be possible.
00:15:17.260
However, we must motivate the community to achieve this goal.
00:15:23.070
We have some new technologies in development.
00:15:30.970
MRI stands for Matz's Ruby Interpreter (not true for Ruby anymore).
00:15:37.580
It includes a JIT compiler facility, making Ruby faster.
00:15:47.120
However, Ruby has constraints due to its history, and the past uses affect memory consumption.
00:15:58.840
Ruby should run on the smallest possible code items.
00:16:04.720
But we can't consume excessive memory to speed it up.
00:16:10.540
That’s a constraint; we need Ruby to maintain memory efficiency.
00:16:21.760
It must also run on many platforms, maintaining compatibility.
00:16:28.420
For instance, we need it to run on various editions of Windows, Mac, and many CPUs.
00:16:37.200
These constraints make upgrades and developments challenging.
00:16:44.400
This year, we are exposed to various developments.
00:16:51.460
Makarov, who developed the new Ruby 3, is doing an incredible job.
00:17:06.000
The important aspect of this new interpreter is optimizing code efficiency.
00:17:13.800
It utilizes a register-based internal representation, improving performance.
00:17:20.460
This new implementation creates fewer instructions, reducing memory traffic.
00:17:27.880
While some may complain about this, it is beneficial overall.
00:17:35.480
With Ruby 3, we can expect faster speeds without significantly increasing memory usage.
00:17:42.460
The low memory usage is crucial, as it allows for smoother operations.
00:17:50.460
Adapting our approach to memory can significantly improve Ruby's performance.
00:17:56.740
The idea is to keep dependencies to a minimum, maintaining control.
00:18:03.120
We should avoid dependence on third-party libraries due to maintainability issues.
00:18:10.740
We need to ensure projects are self-sustaining within Ruby.
00:18:19.080
The libraries should not also consume excessive memory, as this could lead to bottlenecks.
00:18:25.570
The memory usage needs to be as optimized as possible while maintaining functionality.
00:18:33.080
Ruby runs on various platforms and needs to adapt to those changes.
00:18:42.240
With new technological advancements, we can seamlessly transition these benefits to Ruby.
00:18:50.420
We’ve had consistent discussions on how Ruby can evolve to maintain functionality.
00:18:58.750
With this level of improvement, we must remember to gauge the community's interest.
00:19:05.990
Adding new features is an important aspect of our development process.
00:19:14.270
This ensures that we keep Ruby relevant.
00:19:20.080
To do this, we need to have clearer communication with the community.
00:19:28.200
We need to keep everything simplified while also adding more.
00:19:36.630
Recently, we've supported Unicode 10, making Ruby more internationally friendly.
00:19:44.180
Then we've included new performance metrics, covering traceability.
00:19:51.670
We added better debugging, profiling, and coverage features.
00:19:56.750
Enhancing user experience through error messages is also crucial.
00:20:02.810
These improvements are necessary for a richer experience in Ruby.
00:20:09.500
Maintaining compatibility is key.
00:20:17.180
We consistently aim to add functionality without compromising existing features.
00:20:25.520
For instance, we introduced classes and methods to increase versatility.
00:20:34.230
However, string manipulation became complex, needing new approaches.
00:20:42.720
Characters need to represent more than just a set of bytes.
00:20:50.400
So, we are focusing on supporting multiple characters extensively.
00:20:57.780
Now, we are empowered to process thousands of characters easily.
00:21:05.350
With this, it allows Ruby to be even more user-friendly.
00:21:14.980
The combination of two code points creates unique identifiers.
00:21:24.120
This introduces a new layer of flexibility in programming.
00:21:33.120
Combining different attributes enables better character representation.
00:21:42.720
Recent Unicode developments are empowering Ruby and its users.
00:21:50.560
We are reviewing some of our existing features for improvements.
00:22:04.520
Potential changes can invoke mixed feelings; however, it's all for the better.
00:22:14.020
Adopting changes must align with community needs.
00:22:21.400
Ruby’s design must evolve to cater to the developer community.
00:22:28.930
Language design changes have shifted as the community matures.
00:22:36.480
As designers, we remain open to suggestions.
00:22:44.560
We are here to gather feedback and insights from everyone.
00:22:50.060
This input is crucial as we design the next iterations of Ruby.
00:22:58.230
To summarize today's discussion: we must continue to welcome changes.
00:23:03.560
Maximizing good changes while minimizing disruptions should be our goal.
00:23:10.750
Ruby was designed with the programmer in mind, focusing on usability.
00:23:18.330
I aimed to create a language that I would enjoy using, and thankfully many others have enjoyed it as well.
00:23:30.250
Our users mean a lot to us, and we want to help reduce mistakes shared in the community.
00:23:41.500
As we approach Ruby's 20th birthday on February 24th, 2015, we are planning a celebration.
00:23:50.870
Although attendance may be limited, we are also considering a virtual event.
00:24:02.860
We invite everyone to tweet their memories or inspirations related to Ruby.
00:24:10.350
We want to compile these into a digital scrapbook for everyone to view.
00:24:18.090
This is just the beginning of our collective journey with Ruby.
Explore all talks recorded at RubyConf 2017
+79