3 ms·

> I’m surprised they didn’t opt to do this inline with the rest of the ruby code, As they mention in the post, they followed typescript's approach, here. The

> I’m surprised they didn’t opt to do this inline with the rest of the ruby code, As they mention in the post, they followed typescript's approach, here. The benefit is it allows you to layer in typing into an existing codebase in a non-disruptive way.

azinman2 6y ago
But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.
- ativzzz 6y ago
  Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.
  - joshuamorton 6y ago
    You can do both. Python allows for external .pyi files, for situations where you can't modify the underlying library (for example: it's written in C). There are tons of them: https://github.com/python/typeshed https://github.com/python/typeshed, but you can still add types to new code inline.
    - ativzzz 6y ago
      You can, but clearly the people designing this system have weighed the pros and cons and found that there would be more benefits to them to leave the source code unchanged.
      - baweaver 6y ago
        Yeah, there was a ton of discussion on this in the Ruby bugtracker and at core meetings. Matz is very sensitive to breaking the language with Ruby 3 and the core team is doing their best to ensure an easy transition.
  - mekster 6y ago
    So, why would a company with different use case than average ruby users implement stuff in the core to confuse many ruby users?
  - mekster 6y ago
    That use case is not for most of us yet the way those companies with large code base goes into the core? I guess ruby itself already has a large code base, so it seems they got aligned but they forgot to align with the rest of the world.
- punnerud 6y ago
  You can run Python type check before runtime at the cost of start time, or better before GIT commit or push (Git Hooks)
- Lio 6y ago
  Inline types are available as a feature of the Sorbet type checker.
untog 6y ago
> As they mention in the post, they followed typescript's approach, here. They didn't, though! That's what's confusing me. TypeScript has inline types. .d.ts files are typically for JavaScript files that don't have types embedded.
- CarelessExpert 6y ago
  > They didn't, though! That's what's confusing me. Sure they did. It's the 5th paragraph in the post: "We defined a new language called RBS for type signatures for Ruby 3. The signatures are written in .rbs files which is different from Ruby code. You can consider the .rbs files are similar to .d.ts files in TypeScript or .h files in C/C++/ObjC. The benefit of having different files is it doesn't require changing Ruby code to start type checking. You can opt-in type checking safely without changing any part of your workflow."
  - untog 6y ago
    They've described part of TypeScript's approach. .rbs files: have types .rb files: no types .d.ts files: have types .ts files: have types It's a pretty significant difference. So they didn't "follow typescript's approach" here.
    - floatboth 6y ago
      Well, .rb types won't have the standard type signatures (that could be consumed by various typecheckers) but could still have a particular typechecker's custom annotations…
tdeck 6y ago
But that's not really TypeScript's main approach, is it? When I think of TypeScript I think of the inline colon annotations, not the external files. Those are just a bridge for legacy code.

azinman2 6y ago

But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.

ativzzz 6y ago
Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.
- joshuamorton 6y ago
  You can do both. Python allows for external .pyi files, for situations where you can't modify the underlying library (for example: it's written in C). There are tons of them: https://github.com/python/typeshed https://github.com/python/typeshed, but you can still add types to new code inline.
  - ativzzz 6y ago
    You can, but clearly the people designing this system have weighed the pros and cons and found that there would be more benefits to them to leave the source code unchanged.
    - baweaver 6y ago
      Yeah, there was a ton of discussion on this in the Ruby bugtracker and at core meetings. Matz is very sensitive to breaking the language with Ruby 3 and the core team is doing their best to ensure an easy transition.
- mekster 6y ago
  So, why would a company with different use case than average ruby users implement stuff in the core to confuse many ruby users?
- mekster 6y ago
  That use case is not for most of us yet the way those companies with large code base goes into the core? I guess ruby itself already has a large code base, so it seems they got aligned but they forgot to align with the rest of the world.
punnerud 6y ago
You can run Python type check before runtime at the cost of start time, or better before GIT commit or push (Git Hooks)
Lio 6y ago
Inline types are available as a feature of the Sorbet type checker.

untog 6y ago

> As they mention in the post, they followed typescript's approach, here. They didn't, though! That's what's confusing me. TypeScript has inline types. .d.ts files are typically for JavaScript files that don't have types embedded.

CarelessExpert 6y ago
> They didn't, though! That's what's confusing me. Sure they did. It's the 5th paragraph in the post: "We defined a new language called RBS for type signatures for Ruby 3. The signatures are written in .rbs files which is different from Ruby code. You can consider the .rbs files are similar to .d.ts files in TypeScript or .h files in C/C++/ObjC. The benefit of having different files is it doesn't require changing Ruby code to start type checking. You can opt-in type checking safely without changing any part of your workflow."
- untog 6y ago
  They've described part of TypeScript's approach. .rbs files: have types .rb files: no types .d.ts files: have types .ts files: have types It's a pretty significant difference. So they didn't "follow typescript's approach" here.
  - floatboth 6y ago
    Well, .rb types won't have the standard type signatures (that could be consumed by various typecheckers) but could still have a particular typechecker's custom annotations…

tdeck 6y ago

But that's not really TypeScript's main approach, is it? When I think of TypeScript I think of the inline colon annotations, not the external files. Those are just a bridge for legacy code.