00:00:15.679
How's everything going? Great, good. Do you have a good conference so far? Oh, good, tired. I'm a little tired, I won't lie.
00:00:22.599
It’s been a good conference so far, yes? Yeah, good. I missed several sessions, so... yeah, I’m...
00:00:35.879
I’m sorry. No, it's fine. Not at all. So, we'll jump right into the questions. There are some questions about your presentation from the first day.
00:01:08.400
One of the questions was about type inference. People were interested if you could talk a little bit more about that. Maybe discuss how dynamic methods and metaprogramming fit in with that.
00:01:14.640
And sort of when would the type checking happen? Would the program ever type check itself, or would it just be a database? The type checking will be done at compile time, so we cannot check things that happen dynamically, like `eval` or `define_method`. In those cases, we just ignore them.
00:01:51.360
At the beginning, I'll create something like a prototype of the independent type checker. You can consider these type errors as warnings for your program. They might be false positives due to missing methods or dynamic evaluations. But the type checker can warn you that we cannot determine those kinds of errors at compile time.
00:02:22.560
Compile time is such a vague term with Ruby, right? It's not like C where we know there's a specific time for compiling and another for running. In Ruby, compile time is this strange time while we're running the code that sets up the other code.
00:02:37.120
So do you think that the stuff that runs at compile time will be able to see through `require` statements?
00:02:49.720
Yes, it would be able to see into gems, for instance. But the reference is quite limited. The compile time type checker requires looking for the library source code and reading into it.
00:03:20.080
Do you think of the type checker as part of the normal loader, or is it a separate thing looking at the code? It's a separate thing, at the beginning.
00:03:37.120
Okay, cool. If this is too vague, feel free to ask more questions. We have some audience questions already.
00:03:57.199
Is this topic related, or is it something different entirely? It's on `gills`. That's fine. Well, go ahead and ask your question.
00:04:09.239
Can they all be this close? This is not easy. Yeah, I didn’t want to make you run. I could ask a similar question regarding type checking. In your presentation, you mentioned you were looking at this but could throw it out, similar to what you did last year.
00:04:41.320
What other methodologies have you considered that are number two or three on the list? Or are there no contenders for number two or three at this point?
00:05:16.640
You mean for type checking? Like what crazy idea do you have when you walk the dog? That’s when I have all my crazy ideas, usually in the shower.
00:05:54.639
For type checking, I don't have any crazy ideas right now. The usual compile time information is pretty limited for Ruby programs because we generally have very little data available.
00:06:40.120
We can infer something from assignments or literals, but otherwise, we don't have information regarding argument types, return value types, or enough data.
00:07:09.800
To complement that, we could add some kind of database to gather runtime information or pull method set information from a running program, checking for inconsistencies.
00:07:44.480
Did you look at other attempts that people have made?
00:08:00.760
In your presentation, you said that past research or attempts, like Diamondback for example, tended to force too many type annotations. Is that your main takeaway from those past attempts?
00:08:42.560
I did a bit of survey of the previous US research, and the two takeaways are: gathering compile time information from non-typed, non-annotation code isn't really good enough.
00:09:21.520
I saw that the previous attempts, including Diamondback, ultimately failed or gave up. We clearly need something additional, like a gathering of runtime type information.
00:09:50.860
This is my attempt to provide more detailed programming structure information.
00:10:23.320
How do you expect people to interact with type checking? Would the check occur while running code or before checking it into Git?
00:10:54.440
Fundamentally, I want the compiler or type checker to read our intentions from the code. You don’t have to interact at all. At least in the short term, we can read the documentation, which often includes return and argument value types.
00:11:30.660
We can extract that information, and in the future, we can reverse this process to enhance documentation.
00:11:59.260
Now, we can open the floor for more questions. Is it a good time to change topics? Absolutely.
00:12:25.160
So, Mats, I know that MRuby is not a fork but a brand new codebase off of 1.9, correct? It wasn’t forked from 1.9?
00:12:47.680
Right. I utilized some description from 1.9’s source code, but modified it a lot. So, I don’t consider MRuby to be a fork.
00:13:16.320
So what would it take to integrate performance and GC improvements from the current Ruby into MRuby?
00:13:53.839
The biggest improvement made after 1.9 was having a generational and incremental garbage collector from day one. We don’t have to revisit that improvement in MRuby.
00:14:45.200
What about other improvements, like making hashes faster? How do we transfer Ruby code into MRuby?
00:15:08.600
It's certainly possible, but we have different criteria for including things in MRuby. For example, the MRuby design should minimize memory consumption, so improvements that consume more memory may not be integrated.
00:15:42.520
Open addressing for hashes, however, is one idea that should be considered for MRuby.
00:16:21.240
You can’t pick a favorite between CRuby and MRuby, but do you find that you've made decisions in MRuby that you like more than CRuby?
00:16:30.520
Yes, I have two aspects in MRuby that are better than in CRuby. One is that MRuby drops the legacy cryptic variables like dollar-variables.
00:17:07.000
And the second improvement is MRuby has an embeddable API that makes it better to embed a Ruby VM into your application.
00:17:44.400
We have people raising their hands in the middle of the seats. If we're lining up, let’s start.
00:18:17.680
Hello! Mats, can you give an update on your Ruby 3x3 plan announced last year? What progress has been made?
00:18:43.760
For example, the upcoming Ruby 2.4 will feature faster hashes and faster rational numbers, including various performance improvements.
00:19:10.400
Ruby 2.4 will also be slightly faster than Ruby 2.3. So we’re adding those improvements until we achieve the targeted three times speed performance.
00:19:49.320
Would releases serve as a status report for Ruby 3? As new releases come out, we should see improvements in performance for our benchmarks, correct?
00:20:22.760
Yes, we’re also preparing a web application benchmark alongside the previous benchmarks for Ruby’s performance.
00:20:48.080
While we can run the benchmarks repeatedly, no one really uses them during real application development.
00:21:11.560
You might consider an interesting question: you are very intent on not breaking backwards compatibility, which is commendable.
00:21:35.140
If there were no drawbacks, what are your top three Ruby features you would remove?
00:21:57.200
I'd remove the following: the inherited variables from Perl, threads, and perhaps turn `eval` into a keyword.
00:22:16.240
So some of my friends suggested that there should be a one-word answer to this question.
00:22:58.960
Regarding the new concurrency model, why didn't you adopt actors?
00:23:31.280
We aimed to keep compatibility without breaking prior versions. We need to maintain a consistent thread model.
00:23:58.920
Ask him later. Personally, I would have liked actors to be used, but that wasn’t feasible.
00:24:32.880
Contributing to Ruby as a new contributor seems a bit tricky, with talk of friction in the process.
00:24:59.520
Is the core team considering ways to ease the contribution process for new contributors?
00:25:27.680
Indeed, Ruby has a long history of development with multiple constraints. We've made improvements, such as having GitHub repositories.
00:25:51.960
While I'm not sure what else we can improve, if you have ideas, just submit them to Ruby's issue tracker.
00:26:28.240
Are there particular areas of Ruby that need attention from contributors?
00:26:54.840
Sometimes we have developer meetings, and we identify areas where we can cooperate and contribute.
00:27:20.320
At one point, there was a big push to improve documentation. Do you think that initiative was successful?
00:27:40.680
Yes, that push was quite successful. If you encounter undocumented aspects or need clarification, please submit a pull request.
00:28:04.320
Ruby technically supports tail call optimization but is difficult to access. Will you make it more straightforward?
00:28:38.760
We ignored all requests for tail call optimization because we've implemented it but kept it disabled by default.
00:29:08.680
We have few requests regarding it, and most don't require it.
00:29:33.680
Do you prefer self-tail recursion or mutual tail recursion?
00:30:06.680
We're focused on the stack traces as this is important for debugging, and we need to keep all function calls.
00:30:34.480
It’s still up for discussion how to introduce a new syntax or feature for tail calls.
00:30:57.760
Are you still passionate about maintaining Ruby, and what keeps your interest alive?
00:31:22.440
I still enjoy maintaining Ruby. I don't code myself consistently for CRuby, but I enjoy designing and making decisions for the language.
00:31:43.160
Back when I was an early user of Ruby, I was afraid of the lack of documentation.
00:32:07.360
When I first started, I was concerned at the absence of any form of documentation, even on code comments.
00:32:29.760
I once circulated Ruby in a limited format, and even then, there was a make file.
00:32:55.920
However, it wasn't comprehensively documented, and users were basically on their own.
00:33:15.240
In the context of Brazilian Ruby developers, there's movement to extract parts of the standard library into their own repositories for ease of maintenance.
00:33:51.720
To achieve a proper RubyGems ecosystem, I decided to bundle everything into one distribution, enabling users to install Ruby and access the necessary libraries for web applications.
00:34:28.160
As time progressed, some maintainers disappeared, which resulted in unmaintained libraries in the standard distribution.
00:35:05.560
To resolve this, we've gradually moved certain libraries from the standard distribution to RubyGems.
00:35:35.240
For instance, we've recently placed `tk` outside the standard distribution, allowing for independent updates.
00:36:02.200
We have a list of maintainers and could use more volunteers for unmaintained libraries. If anyone is interested, please raise your hand.
00:36:27.240
As a language designer, Ruby 2 has provided a smooth upgrade path for many users.
00:37:02.200
Are there any regrets from Ruby 2's design that you wish to address in Ruby 3?
00:37:36.680
I’d say that I try to maintain compatibility for no reason, and if there's no compelling reason to break it, I'd like to avoid unnecessary changes.
00:38:06.560
In terms of performance unification, we've noticed backwards incompatibilities in Ruby 2 and ongoing tweaks to fix them.
00:38:43.040
If we can effectively reduce the nitty-gritty of compatibility issues, we should consider targeting the features that minimize user frustration.
00:39:09.560
During discussions about a potential code of conduct for Ruby, you mentioned a desire not to permanently ban anyone from the community. Can you explain why?
00:39:50.880
The Ruby community is expansive, and no one truly initiates or gains membership, so I cannot see the justification behind banning someone from such a broad community.
00:40:30.680
However, if we have a stricter definition, like attendees of conferences, it's possible to manage those scenarios.
00:41:05.000
Is it conceivable that we could ban people from the core team if they participated unfavorably?
00:41:51.000
Indeed, that discussion revolves around establishing conduct within the Ruby core team, contrasting the broader Ruby community.
00:42:30.480
For returning questions, it's essential to reflect on where Ruby sees itself in the next 5 to 10 years.
00:42:58.720
The Ruby language will keep improving and adapt to the shifting technological landscape.
00:43:03.999
With advancements in technology, like accommodating multicore processors, Ruby aims to remain a powerful, adaptable programming language.
00:43:45.438
Mats, I’ve always been confused about the design of private and protected methods. There have been mention of regrets about naming. Will there be changes to clarify this?
00:44:18.260
I confess regret around private vs protected methods. However, I believe fixing naming without breaking compatibility may be challenging.
00:45:15.220
To conclude our session, we must consider how many people effectively utilize protected methods.
00:45:38.200
If you aren’t using them, there could be room for refining or possibly transitioning to different paradigms.
00:46:09.640
Have you drawn inspiration from languages like Elixir, Closure, or Scala while working on Ruby’s design?
00:46:42.280
Yes, I'm very interested in various programming languages, including Elixir for concurrency and Closure for functional features.
00:47:06.680
Perl, which influenced Ruby originally, has released Perl 6 recently. Anything noteworthy you've learned from Perl 6?
00:47:59.280
I'm quite impressed with how Ruby has influenced Perl 6 and their design features, such as internal DSLs that introduce new syntax.
00:48:30.640
As we approach the end of our time, I want to thank you, Matz, for your insights and our engaged audience for the questions.
00:49:03.640
Our RubyConf has been a great experience, and we appreciate everyone's participation. Thank you for joining us!
