←back to thread

511 points mootrichard | 10 comments | | HN request time: 0s | source | bottom
Show context
avolcano ◴[] No.23990374[source]
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.

replies(7): >>23990471 #>>23990726 #>>23991491 #>>23992023 #>>23992155 #>>23992440 #>>23995093 #
1. ric2b ◴[] No.23992023[source]
> 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.

replies(3): >>23992620 #>>23993798 #>>23994822 #
2. cutler ◴[] No.23992620[source]
Surely a good IDE such as RubyMine would be able to display the type in reponse to, say, a mouseover?
replies(1): >>23993178 #
3. derwiki ◴[] No.23993178[source]
RubyMine tries but it certainly works less well than PyCharm and GoLand.
replies(3): >>23994829 #>>23995686 #>>23995884 #
4. inopinatus ◴[] No.23993798[source]
It also leaves a big question-mark over how this fits into the REPL, and how we might create type definitions dynamically, since many classes in a running Ruby application are conjured by frameworks.
5. halostatue ◴[] No.23994822[source]
At the moment, I’m disappointed in Sorbet’s capabilities‡, and it’s definitely not usable to me for the libraries that I maintain. I will (theoretically) be able to use Steep with _zero_ negative impact on deliverability.

https://github.com/sorbet/sorbet/issues/3252

6. d3nj4l ◴[] No.23994829{3}[source]
RubyMine works great if you add yard type docs to your code.
replies(1): >>23995187 #
7. Lio ◴[] No.23995187{4}[source]
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.

replies(1): >>23996315 #
8. imhoguy ◴[] No.23995686{3}[source]
Go is statically typed.
9. vidarh ◴[] No.23995884{3}[source]
But that is because it lacks type information. With type information added via RBS (or whatever other mechanism), they'd be able to parse that.
10. d3nj4l ◴[] No.23996315{5}[source]
It doesn't do typechecks, no. You can use solargraph (https://github.com/castwide/solargraph) for that.