12 ms·

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

by muglug 6y ago

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.

skywhopper 6y ago
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.
- baweaver 6y ago
  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-argument-pain-point/74980 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.
  - Jabbles 6y ago
    His view is probably informed by the Python 2->3 experience.
    - baweaver 6y ago
      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.
    - jrochkind1 6y ago
      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.
      - dragonwriter 6y ago
        > 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.
        Polylactic_acid 6y ago
        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.
        riffraff 6y ago
        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.
      - baweaver 6y ago
        That's definitely fair, and probably a large reason why they're so paranoid about repeating that.
    - dragonwriter 6y ago
      And also the Ruby 1.8->1.9 experience.
- yawaramin 6y ago
  > 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.
burke 6y ago
Because Matz won't let people add type annotations to the ruby grammar.
- jakearmitage 6y ago
  Which is great.
  - zeptonix 6y ago
    Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy to catch/fix or show up straight away when running an app. It's mostly a documentation system. And it slows development down. Especially in Ruby which is such an elegant "programmer's language" I think it would just be silly.
    - sparker72678 6y ago
      A-fucking-men. In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs. Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics. If you want strong typing, then good for you. Just pick a language that fits that mold. So much of what I love about Ruby is what it doesn't make me do.
      - jolux 6y ago
        Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.
        6y ago
regularfry 6y ago
I can well imagine that it might be because ruby's formal syntax is already utterly bonkers, and the thought of adding types to it in any usable fashion gave someone a seizure.
- rudolph9 6y ago
  Haven't used ruby in years for the typical reasons people move away from it (performance, strong types, GVL, etc.) but syntax is #1 reason I like programming in Ruby. I did mostly ruby for about 5 years and really grew to love it! It may seem bonkers at first but quite enjoyable once you understand it. Now nearly 4 years later of mostly javascript, golang, python, haskell I still regularly stop and think to my self how much I miss ruby!
  - regularfry 6y ago
    As an end user, it's amazing. I do have sympathy for the implementers, though.
  - hrktb 6y ago
    I read parent’s “bonkers” in a positive way. Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name: String)“. In ruby it’s of course already taken, in no small part because there are 3 or 4 different ways to declare hash parameters. I’d imagine most decent syntax candidates had similar issues, due to ruby’s syntax versatility.
    - Polylactic_acid 6y ago
      The worst part of ruby imo is the fact that a hash can have both string and symbol keys. Countless times I have encountered issues where a function takes an options hash and the callers use both string and symbols for the same key depending on which caller it is. I end up calling the function to convert to symbols all the time.
      - rudolph9 6y ago
rattray 6y ago
I wonder what percentage of TypeScript users write their types inline, and what percentage of users choose to write separate .d.ts files for each of their source files. My guess is the latter is vanishingly small – that it's pretty much only done for libraries that were written before TS was a thing – so I wonder how things will go in Ruby. Maybe everybody will just standardize on third-party tools like Sorbet which allow inline typedefs, or use types a lot less, or hook up a "regenerate inferred .rbs on save" workflow in their editor, or just switch between files a lot.

by muglug 6y ago

skywhopper 6y ago

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.

baweaver 6y ago
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-argument-pain-point/74980 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.
- Jabbles 6y ago
  His view is probably informed by the Python 2->3 experience.
  - baweaver 6y ago
    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.
  - jrochkind1 6y ago
    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.
    - dragonwriter 6y ago
      > 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.
      - Polylactic_acid 6y ago
        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.
      - riffraff 6y ago
        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.
    - baweaver 6y ago
      That's definitely fair, and probably a large reason why they're so paranoid about repeating that.
  - dragonwriter 6y ago
    And also the Ruby 1.8->1.9 experience.
yawaramin 6y ago
> 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.

burke 6y ago

Because Matz won't let people add type annotations to the ruby grammar.

jakearmitage 6y ago
Which is great.
- zeptonix 6y ago
  Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy to catch/fix or show up straight away when running an app. It's mostly a documentation system. And it slows development down. Especially in Ruby which is such an elegant "programmer's language" I think it would just be silly.
  - sparker72678 6y ago
    A-fucking-men. In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs. Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics. If you want strong typing, then good for you. Just pick a language that fits that mold. So much of what I love about Ruby is what it doesn't make me do.
    - jolux 6y ago
      Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.
      - 6y ago

regularfry 6y ago

I can well imagine that it might be because ruby's formal syntax is already utterly bonkers, and the thought of adding types to it in any usable fashion gave someone a seizure.

rudolph9 6y ago
Haven't used ruby in years for the typical reasons people move away from it (performance, strong types, GVL, etc.) but syntax is #1 reason I like programming in Ruby. I did mostly ruby for about 5 years and really grew to love it! It may seem bonkers at first but quite enjoyable once you understand it. Now nearly 4 years later of mostly javascript, golang, python, haskell I still regularly stop and think to my self how much I miss ruby!
- regularfry 6y ago
  As an end user, it's amazing. I do have sympathy for the implementers, though.
- hrktb 6y ago
  I read parent’s “bonkers” in a positive way. Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name: String)“. In ruby it’s of course already taken, in no small part because there are 3 or 4 different ways to declare hash parameters. I’d imagine most decent syntax candidates had similar issues, due to ruby’s syntax versatility.
  - Polylactic_acid 6y ago
    The worst part of ruby imo is the fact that a hash can have both string and symbol keys. Countless times I have encountered issues where a function takes an options hash and the callers use both string and symbols for the same key depending on which caller it is. I end up calling the function to convert to symbols all the time.
    - rudolph9 6y ago

rattray 6y ago

I wonder what percentage of TypeScript users write their types inline, and what percentage of users choose to write separate .d.ts files for each of their source files. My guess is the latter is vanishingly small – that it's pretty much only done for libraries that were written before TS was a thing – so I wonder how things will go in Ruby. Maybe everybody will just standardize on third-party tools like Sorbet which allow inline typedefs, or use types a lot less, or hook up a "regenerate inferred .rbs on save" workflow in their editor, or just switch between files a lot.