RBS, Ruby’s new type signature language • Hacker News Board

Re: RBS, Ruby’s new type signature language

#271

Post by michaelfeathers » Thu, Jul 30, 2020, 3:15 AM UTC

setpatchaddress wrote: post #52

I'm really puzzled by the decision to use a separate file for this. The stated justification ("it doesn't require changing Ruby code") doesn't make sense, and my personal experience with languages with external type specifications is strongly negative. It's an unbelievable pain to keep multiple interface files in sync over time. `.h` files are not something to emulate! External interfaces should be generated by tools…

Separate files make sense if you consider typing a form of coupling. I pitched the idea for something like RBS in Ruby back in 2006.

The reasoning is here: https://www.artima.com/forums/flat.jsp?forum=106&thread=1559...

Re: RBS, Ruby’s new type signature language

#272

Post by tdeck » Thu, Jul 30, 2020, 3:20 AM UTC

CarelessExpert wrote: post #10

azinman2 wrote: post #2

Interesting. 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.

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.

Re: RBS, Ruby’s new type signature language

#273

Post by halostatue » Thu, Jul 30, 2020, 4:57 AM UTC

ric2b wrote: post #184

avolcano wrote: post #9

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 Typ…

> 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.

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

Re: RBS, Ruby’s new type signature language

#274

Post by d3nj4l » Thu, Jul 30, 2020, 4:58 AM UTC

derwiki wrote: post #249

cutler wrote: post #227

Earlier quoted context omitted.

Surely a good IDE such as RubyMine would be able to display the type in reponse to, say, a mouseover?

RubyMine tries but it certainly works less well than PyCharm and GoLand.

RubyMine works great if you add yard type docs to your code.

Re: RBS, Ruby’s new type signature language

#275

Post by halostatue » Thu, Jul 30, 2020, 4:59 AM UTC

dragonwriter wrote: post #220

avolcano wrote: post #9

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 Typ…

> 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…

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.

Re: RBS, Ruby’s new type signature language

#276

Post by d3nj4l » Thu, Jul 30, 2020, 5:12 AM UTC

castwide wrote: post #257

I'm still trying to make sense of this announcement. With a lack of type annotation in the Ruby core, I chose to build off YARD to make gradual type safety work. Now I don't know if there will be a standard that supports type safety or if I should continue down the path I'm already following. Help me, Ruby core developers. You're my only hope. (edit: I should have explained that I'm talking about the type checking fe…

Personally, I think you should keep using YARD, because people are bound to be using Ruby <3.0 for a while. As an aside, thanks for solargraph! I can't recommend it enough.

Re: RBS, Ruby’s new type signature language

#277

Post by Lio » Thu, Jul 30, 2020, 5:24 AM UTC

azinman2 wrote: post #15

CarelessExpert wrote: post #10

Earlier quoted context omitted.

> 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.

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.

Inline types are available as a feature of the Sorbet type checker.

Re: RBS, Ruby’s new type signature language

#278

Post by riffraff » Thu, Jul 30, 2020, 5:28 AM UTC

dragonwriter wrote: post #206

jrochkind1 wrote: post #191

Earlier quoted context omitted.

Ruby 1.8 to 1.9 was very painful, I am not sure why it was more succesful than Python 2->3, I'm not sure it "deserved" to be or was any less painful on it's face. It easily could have been just as disastrous. So also informed by that; ruby hasn't done anything nearly as painful since. But that applies to making it so old code does not work in the new version of the language. Nobody expects all new code to work in the…

> I am not sure why it was more succesful than Python 2->3 Probably because Ruby had a much narrower area where it was heavily used, with fewer “finished” but critical libraries.

Matz often cited the "carrot" of much better performance on 1.9 as a reason for the successful transition.

Python3 didn't offer much over python2, so people just saw the downsides, while ruby pushed people to upgrade with the promise that their efforts would gain them better performance and/or save money.

Re: RBS, Ruby’s new type signature language

#279

Post by Lio » Thu, Jul 30, 2020, 5:29 AM UTC

I use unit tests as a design and documentation tool.

Since we already have a specification tool (MiniTest) in the StdLib it would interesting if we could combine the rbs files with spec unit tests.

I already have my matching test file open anyway. Having the typing information in the same place would encourage the use of types, tests and documentation.

Re: RBS, Ruby’s new type signature language

#280

Post by halostatue » Thu, Jul 30, 2020, 5:29 AM UTC

castwide wrote: post #257

I'm still trying to make sense of this announcement. With a lack of type annotation in the Ruby core, I chose to build off YARD to make gradual type safety work. Now I don't know if there will be a standard that supports type safety or if I should continue down the path I'm already following. Help me, Ruby core developers. You're my only hope. (edit: I should have explained that I'm talking about the type checking fe…

Please don’t use YARD. As a documentation format, I find it noisy. As a documentation generator, it doesn’t support standard RDoc syntax (_intentionally_ so) that makes it completely useless.

I say this as someone who has written Ruby for almost twenty years. I will _never_ use a tool that depends on YARD document formatting, because I will never use YARD document formatting.