Ruby Community

Summarized using AI

Opening Keynote: Good Change, Bad Change

Yukihiro "Matz" Matsumoto • November 28, 2017 • Earth

The 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.

Opening Keynote: Good Change, Bad Change
Yukihiro "Matz" Matsumoto • November 28, 2017 • Earth

Opening Keynote - Good Change, Bad Change by Yukihiro Matsumoto

RubyConf 2017

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