00:00:18
So, there were a lot of questions about Ruby 3, which makes sense. I can handle that. Someone asked a question about static typing.
00:00:32
There are multiple questions there. One could be, are you serious about static typing? It really depends on what you mean by 'seriousness.' I like the idea.
00:00:52
You've parsed my intent well, so that’s good. It’s an interesting idea; would that be a fair statement? But if it doesn't pan out, then it might not happen.
00:01:12
We have to experiment with it. I found it very interesting to watch you describe it and mention the fact that...
00:01:39
An example showed a call to `to_int`. If you wanted that to have a static type, what type would you expect for it? This would be easier if I had code to describe it; talking about code in words can be cumbersome.
00:02:19
You would have a method that takes an X, and inside that method, it calls `x.to_int`. What kind of type do you expect X to be responsible for in the method declaration?
00:02:41
In my mind, I expect X to be a #{some_type}, I mean I expect it to be able to respond to `to_int`.
00:03:11
So the type is described by the set of methods it can respond to. Are you thinking of it like Go’s interfaces, where you would define a requirement without saying exactly what type it is?
00:04:02
You wouldn’t say that X is a fixed number because you don’t care, you just need it to have `to_int` available.
00:04:26
You bring up an interesting point. Would you define that as a separate module that just has one method in it, or would you use some construct to describe the signature you want?
00:05:01
Yes, but it would be created inside the compiler, so it would never be exposed outward.
00:05:34
In that particular case, something would check that `to_int` is defined when you call it on X. Would the programmer be expected to add type declarations, or would you prefer more type inference?
00:06:14
Yes, more of a type inference approach sounds interesting. The compiler might provide some information about expected types.
00:06:35
This is all for video clarity. The IDE could use that info for auto-completions or something like that.
00:07:05
You consider that in type inference, it would bubble back up as well, meaning if I passed X as an argument somewhere else, would the requirement for `to_int` propagate back up the call stack?
00:07:51
Yes, that would be interesting.
00:08:29
So if the variable X stated that it needs to respond to `to_int`, that informs the type of the variable, reflecting a kind of conformance.
00:09:13
You're focusing on conformance rather than worrying about runtime performance, correct? This way, when Ruby files load, the compiler can point out potential methods that wouldn’t work.
00:10:12
We had another question: since Ruby 3A might be a good time to remove features while adding others, do you have anything in mind that you would want to remove?
00:10:43
Possibly some of the power inherent in global variables. For example, `$variable`. I’m considering getting rid of some more quirks in the language, but I'm not sure yet.
00:11:25
The last thing I want is to create a huge compatibility gap between versions, like we saw with Python when moving from 2 to 3.
00:12:06
It’s been successful so far with Ruby 2 because of how it allowed dropping replacements to previous versions.
00:12:22
This also applies in some way to Ruby 3.
00:13:23
Now, what about the standard library? There’s been an ongoing effort to ensure there are maintainers for different parts. Some are maintained while others aren’t.
00:14:01
Do you think Ruby 3 is a suitable time to pull out parts of the standard library that aren’t actively being worked on?
00:14:50
We’re in the process of gamifying the standard library. Back in early Ruby versions, we added a lot of functionality because of the battery-included philosophy, and we didn't have RubyGems yet.
00:15:36
These parts have since become outdated and there are some that have gone unmaintained. We need to gradually remove what’s unused.
00:16:25
Sure, it will happen, but maybe in a Ruby 3 or later.
00:17:04
It’s a matter of evaluating what’s still relevant and beneficial.
00:17:31
I am glad you brought up the idea of thread abstraction. We’re still thinking along those lines.
00:18:02
We haven't reached a conclusion yet, but both Koichi and I have strong opinions on the matter.
00:18:55
We do agree that adding a higher-level abstraction for concurrency would be beneficial, but our ideas differ.
00:19:27
In the last year or so, the emphasis on the global interpreter lock (GIL) has changed. People seem to have strong opinions about it.
00:20:12
While the GIL protects users by allowing safe threading, it has led to complaints. I asked to prepare a compiler option to turn off the GIL.
00:21:03
It would demonstrate how difficult it can be to write a thread-safe program without it. It's been quite a challenge.
00:21:44
At present, the parts of Ruby that are thread-safe still run with the GIL. What is run without it is much more limited, such as system calls.
00:22:38
There are still complaints about the GIL, although many parts of Ruby rely on it.
00:23:20
I believe that we need higher abstraction; the current threading model is too primitive for many users.
00:24:06
How about embedding a Ruby interpreter inside C Ruby? Imagine actors running independently, while C Ruby coordinates them.
00:24:51
Actually, there's a guy who wrote an extension that allows embedding Ruby within Ruby on its own heap.
00:25:40
Now, about macros, we received a common question every year regarding Ruby 3 having macros. The answer's straightforward: no.
00:26:23
The short answer is no; the longer answer is still no.
00:27:09
When do you think Ruby core will migrate to git? We've been on Subversion for years.
00:27:56
I'm not sure yet. The coordination team is quite reliant on scripts written around Subversion.
00:28:54
We have a lot of pull requests and issues on GitHub after all. If the majority agrees we can move to Git, it could happen soon.
00:29:43
I also want people to know how you personally use git.
00:30:20
I used to work with quilt and now use G, which is a stack-like tool to organize git commits.
00:30:59
It allows for flexibility, like naming and changing the order of stacks, making it very handy.
00:31:39
Looking at threading in Ruby long-term, if you could envision an ideal threading model, what would that be?
00:32:15
There are many ideas regarding whether to follow the actor model or impose thread association per object.
00:33:09
Koichi suggests that objects should belong to the thread that creates them, meaning only that thread can modify the object.
00:34:01
Objects from other threads could be treated as immutable. For instance, you could grant limited access but not modify.
00:34:49
How about Rust? Have you looked at it? What do you think?
00:35:29
Rust combines system programming with functional programming languages comfortably. I prefer Go for its simpleness.
00:36:10
What are your thoughts on changes to Ruby's syntax to explicitly state a method should or shouldn't return a value?
00:36:51
It’s a complex issue worth exploring. If it could segregate methods that should not return values effectively, that could be interesting.
00:37:39
I've encountered unexpected behaviors because of overloaded return values I’d like to fix.
00:38:13
I have found unbound methods quite fascinating; they allow for methods to be invoked without attaching to an instance, allowing for more dynamic behavior.
00:39:02
Yet, when we bind them, they still check if the object receiving the binding is an appropriate ancestor.
00:39:46
It seems like this experimentation could deepen understanding of Ruby's object system. Do you want to add anything?
00:40:27
Your feedback on soft typing would certainly be beneficial when considering future Ruby implementations.
00:41:18
I plan to release tools for static analysis related to soft typing soon, looking forward to the community's input after that.
00:42:05
The Ruby ecosystem expands—each implementation serving a different niche can lead to a more vibrant community.
