6 ms·

Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :) It does seem u

Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :) It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a .d.ts file - as that allows for different type checking implementations to use the same system under the hood. This was a big problem for Flow, and why it lost the fight as soon as TypeScript's definitely-typed repository started gaining momentum - users wanted to use the type-checker that they knew had definitions for the libraries they used. On the other hand, RBS as hand-written seems rather dangerous, to me. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code. Sorbet cleverly (and unsurprisingly, given it's Ruby) used a DSL for definitions in code, which had the (excellent) additional boost of runtime checking, so you actually could know whether your types were accurate - by far the biggest pain-point of erased-type systems like TypeScript. Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code, and instead will focus on external type checking. I might be missing a piece of the full puzzle not covered in the blog post, however.

ucarion 6y ago
For other readers: "Sorbet" refers to https://sorbet.org/ https://sorbet.org/, Stripe's Ruby type checker.
- avolcano 6y ago
  apologies, meant to add that as a link when I referenced Stripe in the first sentence!
shpongled 6y ago
I'm not familiar with Ruby at all, but presumably it'd be possible to at least generate stubbed out definition RBS files with type inference.
- baweaver 6y ago
  It is, and checkers like Steep and Sorbet can infer these types. We're currently playing with the idea of deriving from documentation like YARDoc as well.
  - rattray 6y ago
    https://github.com/AaronC81/sord https://github.com/AaronC81/sord is one attempt at this
judofyr 6y ago
> On the other hand, RBS as hand-written seems rather dangerous, to me. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code. Isn't the point that you run the type checker on your own code and it checks that it implements the signature correctly? Having a mismatch between the code and the signature will give a type error. How is this different from how Sorbet works?
ric2b 6y ago
> I'm surprised that it does not seem to have syntax for type definitions in code This is a big disappointment to me, one of the main advantages of static typing is that it can make code much easier to understand when types are added to non-obvious method parameters.
- cutler 6y ago
  Surely a good IDE such as RubyMine would be able to display the type in reponse to, say, a mouseover?
  - derwiki 6y ago
    RubyMine tries but it certainly works less well than PyCharm and GoLand.
    - d3nj4l 6y ago
      RubyMine works great if you add yard type docs to your code.
      - Lio 6y ago
        Is it checking those types or just reporting then? I’ve seen so many instances where yard doc has the wrong return type or misses a return type that I rarely trust it.
        d3nj4l 6y ago
        It doesn't do typechecks, no. You can use solargraph (https://github.com/castwide/solargraph https://github.com/castwide/solargraph) for that.
    - imhoguy 6y ago
      Go is statically typed.
    - vidarh 6y ago
avodonosov 6y ago
It must be a very easy next step to allow type declaration inline with the code, for example as comments of special format, or maybe some meta-fields / annotations (I'm not a rubyist so don't know whether the language allows associating custom meta information with program elements).
- chc 6y ago
  I mean, the most obvious solution would just be to unify Ruby's basic syntax with the RBS syntax shown in the OP. This format already looks like a Ruby class definition with the method bodies omitted and some simple "-> type" and ": type" syntax added. I think that's why people find the separation confusing.
  - dragonwriter 6y ago
    > This format already looks like a Ruby class definition with the method bodies omitted and some simple "-> type" and ": type" syntax added The thing is that much of it is perfectly valid Ruby code with wildly different semantics already, so, no, without breaking a lot, you can't unify it with Ruby syntax.
- dragonwriter 6y ago
  > It must be a very easy next step to allow type declaration inline with the code Updating Ruby’s already notoriously complex syntax to support type annotations while keeping existing Ruby code valid with it's existing semantics is...not a very easy step, I suspect. Annotations in documentation is a more viable way of integrating type definitions into program source files.
  - digitaltrees 6y ago
    This is the first I have ever heard of ruby syntax as notoriously complex. If anything it’s usually the opposite. I would love to read why people say that about ruby.
    - 6y ago
dragonwriter 6y ago
> On the other hand, RBS as hand-written seems rather dangerous, to me. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code. That’s sounds like what type-profiler, mentioned in the article, is for; it's an experimental project which,if successful, seems destined to be part of Ruby’s bundled command line tooling, for generating type signatures from code. If you mean you want type signatures embedded in code source files rather than in separate files, they seem to be taken a documentation-annotation approach, with YARD documentation format expressly called out as a mechanism to bed typing in source files. That's probably cleaner than further cluttering Ruby’s syntax with annotations. > Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code The support seems to be that, at a minimum, that it will have a standard for type definitions and provide them for Core and Stdlib and have command line tooling for working with type definitions. Which is, I would say, significante support.
- halostatue 6y ago
  I also believe that, at some point, Ruby _will_ support RBS/steep format in the source code, but the advantage to something like .rbs files is that projects that need to support 2.x and 3.x don’t have to maintain two different versions of the code.
bad_user 6y ago
Flow supports importing type definitions for third party untyped libs. And in fact did a better job at being integrated in current projects. Flow lost because the compiler was in really bad shape, slow and frequently crashing. Also their equivalent repository to DefinitelyTyped would ignore PRs for months and years and afaik still does. It's like it was somebody's toy project and its author eventually lost interest. It's a pitty because TypeScript still has unsound generics. But Microsoft know how to make dev tools and maintain them.

ucarion 6y ago

For other readers: "Sorbet" refers to https://sorbet.org/ https://sorbet.org/, Stripe's Ruby type checker.

avolcano 6y ago
apologies, meant to add that as a link when I referenced Stripe in the first sentence!

shpongled 6y ago

I'm not familiar with Ruby at all, but presumably it'd be possible to at least generate stubbed out definition RBS files with type inference.

baweaver 6y ago
It is, and checkers like Steep and Sorbet can infer these types. We're currently playing with the idea of deriving from documentation like YARDoc as well.
- rattray 6y ago
  https://github.com/AaronC81/sord https://github.com/AaronC81/sord is one attempt at this

judofyr 6y ago

ric2b 6y ago

> I'm surprised that it does not seem to have syntax for type definitions in code This is a big disappointment to me, one of the main advantages of static typing is that it can make code much easier to understand when types are added to non-obvious method parameters.

cutler 6y ago
Surely a good IDE such as RubyMine would be able to display the type in reponse to, say, a mouseover?
- derwiki 6y ago
  RubyMine tries but it certainly works less well than PyCharm and GoLand.
  - d3nj4l 6y ago
    RubyMine works great if you add yard type docs to your code.
    - Lio 6y ago
      Is it checking those types or just reporting then? I’ve seen so many instances where yard doc has the wrong return type or misses a return type that I rarely trust it.
      - d3nj4l 6y ago
        It doesn't do typechecks, no. You can use solargraph (https://github.com/castwide/solargraph https://github.com/castwide/solargraph) for that.
  - imhoguy 6y ago
    Go is statically typed.
  - vidarh 6y ago

avodonosov 6y ago

It must be a very easy next step to allow type declaration inline with the code, for example as comments of special format, or maybe some meta-fields / annotations (I'm not a rubyist so don't know whether the language allows associating custom meta information with program elements).

chc 6y ago
I mean, the most obvious solution would just be to unify Ruby's basic syntax with the RBS syntax shown in the OP. This format already looks like a Ruby class definition with the method bodies omitted and some simple "-> type" and ": type" syntax added. I think that's why people find the separation confusing.
- dragonwriter 6y ago
  > This format already looks like a Ruby class definition with the method bodies omitted and some simple "-> type" and ": type" syntax added The thing is that much of it is perfectly valid Ruby code with wildly different semantics already, so, no, without breaking a lot, you can't unify it with Ruby syntax.
dragonwriter 6y ago
> It must be a very easy next step to allow type declaration inline with the code Updating Ruby’s already notoriously complex syntax to support type annotations while keeping existing Ruby code valid with it's existing semantics is...not a very easy step, I suspect. Annotations in documentation is a more viable way of integrating type definitions into program source files.
- digitaltrees 6y ago
  This is the first I have ever heard of ruby syntax as notoriously complex. If anything it’s usually the opposite. I would love to read why people say that about ruby.
  - 6y ago

dragonwriter 6y ago

> On the other hand, RBS as hand-written seems rather dangerous, to me. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code. That’s sounds like what type-profiler, mentioned in the article, is for; it's an experimental project which,if successful, seems destined to be part of Ruby’s bundled command line tooling, for generating type signatures from code. If you mean you want type signatures embedded in code source files rather than in separate files, they seem to be taken a documentation-annotation approach, with YARD documentation format expressly called out as a mechanism to bed typing in source files. That's probably cleaner than further cluttering Ruby’s syntax with annotations. > Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code The support seems to be that, at a minimum, that it will have a standard for type definitions and provide them for Core and Stdlib and have command line tooling for working with type definitions. Which is, I would say, significante support.

halostatue 6y ago
I also believe that, at some point, Ruby _will_ support RBS/steep format in the source code, but the advantage to something like .rbs files is that projects that need to support 2.x and 3.x don’t have to maintain two different versions of the code.

bad_user 6y ago

Flow supports importing type definitions for third party untyped libs. And in fact did a better job at being integrated in current projects. Flow lost because the compiler was in really bad shape, slow and frequently crashing. Also their equivalent repository to DefinitelyTyped would ignore PRs for months and years and afaik still does. It's like it was somebody's toy project and its author eventually lost interest. It's a pitty because TypeScript still has unsound generics. But Microsoft know how to make dev tools and maintain them.