RBS, Ruby’s new type signature language
developer.squareup.com
RBS, Ruby’s new type signature language
1–10 of 340 posts
Re: RBS, Ruby’s new type signature language
#2Interesting. I’m surprised they didn’t opt to do this inline with the rest of the ruby code, because now they can diverge from each other. It’s a bit like a separate header file in C/C++/Obj-C, except in those cases the compiler will yell at you if the implementation doesn’t match the header. Having it blow up at runtime instead doesn’t feel like such a big change from the way it is now, other than helping out IDEs.
Re: RBS, Ruby’s new type signature language
#3Cool. And glad to see this called out:
Better IDE integration: Parsing RBS files gives IDEs better understanding of the Ruby code. Method name completions run faster. On-the-fly error reporting detects more problems. Refactoring can be more reliable!
IDE support (autocomplete, refactoring and quick documentation) is the most important reason to annotate argument and return types.
Re: RBS, Ruby’s new type signature language
#4At some point it makes more sense to switch to Crystal.
Re: RBS, Ruby’s new type signature language
#5Types help communicate information to the next developer. They're important, use them!
Re: RBS, Ruby’s new type signature language
#6How does this interact with method_missing, the soul of rails? Obviously much of the rails api is defined dynamically, not statically. I could see runtime checks having some value but I’m not sure how an IDE could take advantage of this, period. I’d imagine you’d at least need to generate methods (rather than parse and route messages at runtime) to make this remotely viable.
I’m not super familiar with ruby outside of my work so I’m not sure if this reliance on method_missing is more widespread than rails.
Re: RBS, Ruby’s new type signature language
#7At some point it makes more sense to switch to Crystal.
Crystal is amazing (we sponsor it at Fly.io), but the sheer amount of stuff that's already built for Ruby makes it hard to switch to another language.
Node has had 10 years and its still not there.
Re: RBS, Ruby’s new type signature language
#8Cool. And glad to see this called out: Better IDE integration: Parsing RBS files gives IDEs better understanding of the Ruby code. Method name completions run faster. On-the-fly error reporting detects more problems. Refactoring can be more reliable! IDE support (autocomplete, refactoring and quick documentation) is the most important reason to annotate argument and return types.
I've been using typescript for a few years now and to be honest I almost never rely on the compilation errors. I just use the built in Jetbrains IDE completion, autosuggestion, and navigation to make it work.
Re: RBS, Ruby’s new type signature language
#9Didn'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.
Re: RBS, Ruby’s new type signature language
#10Interesting. I’m surprised they didn’t opt to do this inline with the rest of the ruby code, because now they can diverge from each other. It’s a bit like a separate header file in C/C++/Obj-C, except in those cases the compiler will yell at you if the implementation doesn’t match the header. Having it blow up at runtime instead doesn’t feel like such a big change from the way it is now, other than helping out IDEs.
> 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.