Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RBS, Ruby’s new type signature language

developer.squareup.com

Post reply on HN
Print view View original

131–140 of 340 posts

Re: RBS, Ruby’s new type signature language

#131

Post by CarelessExpert »

untog wrote: post #82
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.

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

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

Re: RBS, Ruby’s new type signature language

#132

Post by the_af »

zeptonix wrote: post #95
jakearmitage wrote: post #81

Earlier quoted context omitted.

Which is great.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

> Typing very occasionally prevents bugs that are generally easy to catch/fix or show up straight away when running an app.

This is not true. You could paint almost every language feature aimed at producing correct software in this way: "writing tests makes me type more, and they catch very few bugs that would have been shown when running my app anyway". (Or, as an ex coworker once told me, "I don't need to write tests because I never have any bugs").

And what are types if not a kind of test/proof that the computer writes for you?

> And it slows development down.

There's a software development adage that goes like this: "I don't like writing tests, because they make me waste time I need to fix bugs on production that weren't caught because I don't write tests."

Re: RBS, Ruby’s new type signature language

#133

Post by judofyr »

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.

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?

Re: RBS, Ruby’s new type signature language

#134

Post by vidarh »

danudey wrote: post #116
3pt14159 wrote: post #96

Earlier quoted context omitted.

This is why I do not like mypy or types in Python other than dataclasses. If I'm going to type the damn thing I better be getting performance ala cython. Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. Ruby would do far better to fix the bloody `and` vs `&&` issue (it should just be `and` and it should work like `&&`) and strings should be immutable by default with a special…

> Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. To answer this (as someone who basically only ever writes in Python): There are a few cases where it's really nice to be able to add type annotations to methods or functions. The most obvious example is API calls; it's nice to be able to say "this needs to be a list, give me a list", and not have to do if not isinstance(var,…

I just worry it's going to be abused, though. E.g. I've worked with more than one Ruby code base where someone did a kind_of? check and threw exceptions if it didn't get what it wanted even though the actual type required was anything that implemented a given method in a reasonable way for no good reason.

I hope people keep the type annotations sparse, and allow the tools to infer it unless they're prepared to link long and hard about the minimal restrictions that are reasonable.

Re: RBS, Ruby’s new type signature language

#135

Post by mekster »

amw-zero wrote: post #51
burke wrote: post #48

I absolutely hate this. Separate files for types with no inline annotations possible? What an embarrassing compromise. This is all because Matz explicitly won't allow type signatures in .rb files. I wonder how long it'll be until a hostile fork if he doesn't change his mind.

I wouldn’t call it “embarrassing.” What is the actual benefit of having inline type annotations? What is the actual downside of having them in a separate file?

How hard is it to imagine that you need to keep 2 files in sync, and that you can't type anything inside a method.

I was even hoping to use ruby as a main language having used it before but I'm about to lose any interest in the language when its reality is a bit decoupled from the rest of the world.

Re: RBS, Ruby’s new type signature language

#136

Post by jolux »

zeptonix wrote: post #95
jakearmitage wrote: post #81

Earlier quoted context omitted.

Which is great.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

If your type definitions are 3x longer than the functions implementing them, something is wrong. In languages with complete type inference, you actually don't have to write types at all if you don't want to, though in practice you end up doing so to clarify your intentions.

Static types do make certain classes of bugs impossible, like missing method bugs, typos, and the like. You can eliminate a large group of defensive programming techniques and trivial unit tests that you would need in a dynamic language to ensure a similar level of confidence in a program. Obviously they don't make all bugs impossible, there will be bugs as long as there are programs, because we write programs without perfect knowledge of the requirements, and this is an unavoidable pitfall of software.

Re: RBS, Ruby’s new type signature language

#137

Post by rattray »

freedomben wrote: post #31

I'm not thrilled about the separate files with the type information but I completely understand why they did it, and if it were my choice I might make the same one. I don't like the comparison with TypeScript `.d.ts` files however, because TS still lets you do types inline in the code. I haven't seen it mentioned anywhere that this won't be supported by Ruby 3. Does anybody know if Ruby 3 will also support inline typ…

I don't think Ruby 3 itself will provide a typechecker, just a standard for type definition file formats. You have to use a third-party tool, like Steep or Sorbet, to do the type-checking – and Sorbet at least does support inline type information. See more at my comment here: https://news.ycombinator.com/item?id=23991258

You won't need to use the header RBS files at all (types are optional in any case) but you'll likely want to use Sorbet or Steep to generate them if you're sharing your code more widely, since community tooling like YARD will probably use those for code navigation.

Re: RBS, Ruby’s new type signature language

#138

Post by Thaxll »

kgraves wrote: post #77
Thaxll wrote: post #32

Earlier quoted context omitted.

You don't want to switch to a half baked language for anything serious.

How is Crystal a "half baked language"?

The current state of Crystal is basically a language for PoC during the week-end, it's far from being ready.

I could go on about what's wrong with the language but:

It's not stable, API change all the time, breaking change all the time, cryptic errors, lot of missing basic features, IDE integration etc ...

Re: RBS, Ruby’s new type signature language

#139

Post by jolux »

sparker72678 wrote: post #120
zeptonix wrote: post #95

Earlier quoted context omitted.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

A-fucking-men. In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs. Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics. If you want strong typing, then good for you. Just pick a language that…

Type issues are 0% of your Ruby bugs because you're not using a typechecker. I guarantee you have type errors somewhere if your codebase is large enough.

Re: RBS, Ruby’s new type signature language

#140

Post by mumblemumble »

zeptonix wrote: post #95
jakearmitage wrote: post #81

Earlier quoted context omitted.

Which is great.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

> And it slows development down.

This can depend really heavily on what you mean by "development." If it's just getting the first version banged out, sure. If it includes coming back to code a couple years later in order to incorporate a new business requirement, having that documentation present can be a really big deal. 2 seconds spent typing out a type hint now might, down the line, save several minutes on average. Even in a recent Python project I did over the course of just a couple weeks, when I got to the "clean the code up and get it ready to put on the shelf for now" phase of the project, I ended up wishing that I had bothered to use type hints just a wee bit more when I was banging it out in the first place. It would have been a net time saver.

I don't like static typing super a lot in all cases because it makes it hard to do data-level programming. Which I find to be the true productivity booster in dynamic languages. But optional typing seems to hit the sweet spot for a great many purposes.

Post reply on HN