←back to thread

511 points mootrichard | 1 comments | | HN request time: 0.53s | source
Show context
muglug ◴[] No.23990520[source]
Can someone explain why the types cannot live in Ruby code itself (after an appropriate version bump)?

Python 3 incorporated types into the language itself, in a similar way (though non-reified) to PHP. This seems much easier to deal with than requiring two files (.rb and .rbs) to describe a single data structure.

replies(4): >>23990918 #>>23990947 #>>23991201 #>>23991455 #
skywhopper ◴[] No.23991201[source]
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.
replies(2): >>23991245 #>>24004577 #
baweaver ◴[] No.23991245[source]
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.

replies(1): >>23991273 #
Jabbles ◴[] No.23991273[source]
His view is probably informed by the Python 2->3 experience.
replies(3): >>23991315 #>>23992113 #>>23992181 #
jrochkind1 ◴[] No.23992113[source]
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.

replies(2): >>23992193 #>>23993107 #
1. baweaver ◴[] No.23993107[source]
That's definitely fair, and probably a large reason why they're so paranoid about repeating that.