RBS, Ruby’s new type signature language

Based on the relative smoothness of Ruby version transitions versus Python, I trust Matz’s preference on this implicitly. One good thing about it being external is that you can optionally and experimentally annotate existing code without munging up your source files. At least so long as this is a bleeding edge feature, that separation makes a lot of sense to me. It’ll be a while before anyone can be confident in a particular model for how this should work, until it’s been in use for a good long while.

Pretty much. Matz is very sensitive to breaking the language in any way with the Ruby 3 upgrade, which brought up the true keyword argument hard-break and [likely got that pushed back](https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argume...).

RBS and type files on the side were really hotly debated for a while and the core team settled on this as a way to not break the existing parser among other reasons.

While I don't 100% agree with them I have faith that Matz and the team make the decisions they do based on impact and what they see in the community.

His view is probably informed by the Python 2->3 experience.

It was, and I was around during one of his discussions on that at RubyConf last year. It's a very valid concern and Matz is very sensitive to it. There are a lot of things he's joked about removing or changing but won't because of those reasons.

If you take a look at his keynote video he says quite a bit on this too.

Ruby 1.8 to 1.9 was very painful, I am not sure why it was more succesful than Python 2->3, I'm not sure it "deserved" to be or was any less painful on it's face. It easily could have been just as disastrous. So also informed by that; ruby hasn't done anything nearly as painful since.

But that applies to making it so old code does not work in the new version of the language. Nobody expects all new code to work in the old version of the language. Ruby adds new features including syntax that won't properly parse in old interpreters all the time. It's not clear to me why inline type definitions couldn't be such.

And also the Ruby 1.8->1.9 experience.

> I am not sure why it was more succesful than Python 2->3

Probably because Ruby had a much narrower area where it was heavily used, with fewer “finished” but critical libraries.

I expect most ruby projects only have rails as its core dependency with all other gems being small utility libraries that can be easily updated and replaced. Python gets used for such a wide variety of things.

That's definitely fair, and probably a large reason why they're so paranoid about repeating that.

Matz often cited the "carrot" of much better performance on 1.9 as a reason for the successful transition.

Python3 didn't offer much over python2, so people just saw the downsides, while ruby pushed people to upgrade with the promise that their efforts would gain them better performance and/or save money.

> It’ll be a while before anyone can be confident in a particular model for how this should work, until it’s been in use for a good long while.

Check out the OCaml community, interface files have been use there since basically day one, and are generally well-liked for how clean they allow the implementations to be.