4 ms·

As long as Matz is firmly against, inline typing should never be a part of Ruby. I started working on a large Rails codebase that adopted Sorbet and it is nothi

As long as Matz is firmly against, inline typing should never be a part of Ruby. I started working on a large Rails codebase that adopted Sorbet and it is nothing but an impediment to progress.

throwaway613745 9mo ago
DHH also doesn’t like typing in Ruby at all, and Rails is designed around what he likes.
rco8786 9mo ago
I think it will need to be a strong 3rd party that basically gives it the Typescript treatment. Adds type annotations to the core language syntax. The compiler does type checking, strips the annotations, and outputs plain Ruby.
- anamexis 9mo ago
  Sorbet is backed by Stripe. Why is it important to be a separate layer that compiles to plain untyped Ruby?
  - rco8786 9mo ago
    So that it doesn’t have to go through the Ruby development process. Matz doesn’t want it, and even if he did it would take years just to get people to agree on a syntax, much less actually get it implemented and rolled out. Same reason Typescript was made and we didn’t add types to JavaScript.
    - anamexis 9mo ago
      Is Sorbet not what you’re describing? And RBS is officially part of Ruby…
      - rco8786 9mo ago
        Neither of them integrate annotations into the language. They’re both bolt-ons and it shows, badly. If either of them were good developer experiences one would have caught on. But they’re both way off the beaten path in terms of what engineers expect in a type system and not in a good way. Type annotations in the language as syntax. Static type checker with an emphasis on inference. Compiles into Ruby so that it integrates with the entire existing Ruby ecosystem, so unlike Crystal as well. Those are the general features you need/want and why TS caught on and none of the existing solutions hit the mark.
        __float 9mo ago
        You might find https://blog.jez.io/history-of-sorbet-syntax/ https://blog.jez.io/history-of-sorbet-syntax/ interesting, written by one of the primary contributors to Sorbet. Sorbet is a bit different from TypeScript because it has runtime type checking, not just static.
__float 9mo ago
I work in a large Sorbet codebase (though it isn't a Rails one) and it's a huge boon IMO. The number of tests we don't need to write because of Sorbet is really nice. It does occasionally require structuring your code differently, but I find the type-system-encouraged approach often gives a more elegant and harder-to-misuse interface in the end.
- prh8 9mo ago
  You work in a large Ruby codebase that _isn't_ Rails?! Are you hiring??
  - ezekg 9mo ago
    I was assuming Stripe, but would love to hear of others!
- zingar 9mo ago
  Very curious to hear about the specific cases where types make tests unnecessary. I spend my working life swapping between Ruby and typescript projects and the typescript project is utter garbage with poor test coverage that needs a day of human QA for every build whereas the Ruby project is well tested such that we know that CI passing means it’s good to be released.
  - qaisjp 9mo ago
    Types don't make testing in general unnecessary, but it removes a class of error handling that runtime type checking handles for you. You can really trust the types when using Sorbet. (I also work in a 40m+ loc non-rails ruby codebase that is almost entirely typed with Sorbet.)
    - zingar 9mo ago
      Haha “tell me you work at Stripe without telling me you work at Stripe”
danmaz74 9mo ago
> adopted Sorbet and it is nothing but an impediment to progress How so? I never really missed types in Ruby, even if I like them a lot in typescript, but right now I'm doing some "vibe coding" on a personal project and I was thinking about trying Sorbet. I think that it could help Claude Code avoid some mistakes it often makes which make it waste a lot of time fixing.
- zingar 9mo ago
  Interesting: how is CC in your experience at writing tests and then using them to avoid mistakes?
  - danmaz74 9mo ago
    When writing non-vibe-coded software I use CC a lot to write tests, but I have a skill to tell it not to create redundant tests, which otherwise it tends to do, and I have to check them anyway to ensure that they cover what needs to be covered, and sometimes to trim them down. When vibe coding, what I noticed is that CC tends to make mistakes which it does catch with tests and fix on its own, but my hope is that using Sorbet this will happen much less, and thus development will go faster with less (slow) test cycles.
    - zingar 9mo ago
      Very interested to read the blog post about the results.
- block_dagger 9mo ago
  It’s not a huge impediment but it adds up through: extra lines of sig code I now need to essentially ignore as I read as well as waiting for precommit hooks to check a giant codebase for compliance, plus extra rbi files in git. If engineers followed convention over config and tested types where necessary, no need for inline types. Just use TS if you want types.

As long as Matz is firmly against, inline typing should never be a part of Ruby. I started working on a large Rails codebase that adopted Sorbet and it is nothing but an impediment to progress.

throwaway613745 9mo ago

DHH also doesn’t like typing in Ruby at all, and Rails is designed around what he likes.

rco8786 9mo ago

I think it will need to be a strong 3rd party that basically gives it the Typescript treatment. Adds type annotations to the core language syntax. The compiler does type checking, strips the annotations, and outputs plain Ruby.

anamexis 9mo ago
Sorbet is backed by Stripe. Why is it important to be a separate layer that compiles to plain untyped Ruby?
- rco8786 9mo ago
  So that it doesn’t have to go through the Ruby development process. Matz doesn’t want it, and even if he did it would take years just to get people to agree on a syntax, much less actually get it implemented and rolled out. Same reason Typescript was made and we didn’t add types to JavaScript.
  - anamexis 9mo ago
    Is Sorbet not what you’re describing? And RBS is officially part of Ruby…
    - rco8786 9mo ago
      Neither of them integrate annotations into the language. They’re both bolt-ons and it shows, badly. If either of them were good developer experiences one would have caught on. But they’re both way off the beaten path in terms of what engineers expect in a type system and not in a good way. Type annotations in the language as syntax. Static type checker with an emphasis on inference. Compiles into Ruby so that it integrates with the entire existing Ruby ecosystem, so unlike Crystal as well. Those are the general features you need/want and why TS caught on and none of the existing solutions hit the mark.
      - __float 9mo ago
        You might find https://blog.jez.io/history-of-sorbet-syntax/ https://blog.jez.io/history-of-sorbet-syntax/ interesting, written by one of the primary contributors to Sorbet. Sorbet is a bit different from TypeScript because it has runtime type checking, not just static.

__float 9mo ago

I work in a large Sorbet codebase (though it isn't a Rails one) and it's a huge boon IMO. The number of tests we don't need to write because of Sorbet is really nice. It does occasionally require structuring your code differently, but I find the type-system-encouraged approach often gives a more elegant and harder-to-misuse interface in the end.

prh8 9mo ago
You work in a large Ruby codebase that _isn't_ Rails?! Are you hiring??
- ezekg 9mo ago
  I was assuming Stripe, but would love to hear of others!
zingar 9mo ago
Very curious to hear about the specific cases where types make tests unnecessary. I spend my working life swapping between Ruby and typescript projects and the typescript project is utter garbage with poor test coverage that needs a day of human QA for every build whereas the Ruby project is well tested such that we know that CI passing means it’s good to be released.
- qaisjp 9mo ago
  Types don't make testing in general unnecessary, but it removes a class of error handling that runtime type checking handles for you. You can really trust the types when using Sorbet. (I also work in a 40m+ loc non-rails ruby codebase that is almost entirely typed with Sorbet.)
  - zingar 9mo ago
    Haha “tell me you work at Stripe without telling me you work at Stripe”

danmaz74 9mo ago

> adopted Sorbet and it is nothing but an impediment to progress How so? I never really missed types in Ruby, even if I like them a lot in typescript, but right now I'm doing some "vibe coding" on a personal project and I was thinking about trying Sorbet. I think that it could help Claude Code avoid some mistakes it often makes which make it waste a lot of time fixing.

zingar 9mo ago
Interesting: how is CC in your experience at writing tests and then using them to avoid mistakes?
- danmaz74 9mo ago
  When writing non-vibe-coded software I use CC a lot to write tests, but I have a skill to tell it not to create redundant tests, which otherwise it tends to do, and I have to check them anyway to ensure that they cover what needs to be covered, and sometimes to trim them down. When vibe coding, what I noticed is that CC tends to make mistakes which it does catch with tests and fix on its own, but my hope is that using Sorbet this will happen much less, and thus development will go faster with less (slow) test cycles.
  - zingar 9mo ago
    Very interested to read the blog post about the results.
block_dagger 9mo ago
It’s not a huge impediment but it adds up through: extra lines of sig code I now need to essentially ignore as I read as well as waiting for precommit hooks to check a giant codebase for compliance, plus extra rbi files in git. If engineers followed convention over config and tested types where necessary, no need for inline types. Just use TS if you want types.