Live data from Hacker News

RBS, Ruby’s new type signature language

developer.squareup.com

141–150 of 340 posts

Re: RBS, Ruby’s new type signature language

#141

I likely am missing some context, but the comparison to TypeScript's ".d.ts" files seems misplaced. This is a type signature language, but it does not seem to be a type checker. The comparison to .d.ts files then seems bizarre because that is helpful for language servers¹ to consume types, but there's no proof that say, the implementation matches the type specification. TypeScript declaration files declare what the t…

The type checker implementations (eg; Steep, Sorbet) should throw an error at `return 42`. If `some_function_that_might_not_be_declared_in_an_rbs_file` is not known, the behavior may be configurable – it could be assumed to be something like `any` or assumed to be unsafe, and error until you declare that function. I think Sorbet has this configurability today, and I'm not sure about Steep's behavior.

Steep: https://github.com/soutaro/steep

Sorbet: https://sorbet.org

Re: RBS, Ruby’s new type signature language

#142
post #21

It’s a separate RBS file for now, but if/when this gets integrated into Ruby itself how will it interact with the new Ruby 2.7/3.0 keyword argument syntax that also uses the colon? https://bugs.ruby-lang.org/issues/14183

Difficult questions like that are exactly why matz refused to integrate this into .rb file syntax!

Re: RBS, Ruby’s new type signature language

#143

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

The intention right now is for the StdLib to provide known types to build off of written in RBS. There's no requirement to use them necessarily.

Steep and Sorbet are second-level, they build off of RBS. Matz has mentioned offhandedly in conversations I'd had with him in the past that there's a ton more in store with RBS beyond just type checking, so we'll see where they go with it.

As far as YARDoc I've been eyeing that one for a while now since I first heard about Steep at a Braintree Ruby meetup before Soutaro was at Square. We're still talking about what and how as far as that one.

Re: RBS, Ruby’s new type signature language

#144

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…

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

I'm curious what you mean by "data-level programming."

Re: RBS, Ruby’s new type signature language

#146

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…

FWIW, you can use inline syntax with Sorbet[0], one of the two typecheckers that will work with the RBS format (the other being Steep, which does not have inline syntax). Here's a full example, complete with a typo, based on the example in the blog post: https://bit.ly/3hMEMSp Here's a truncated excerpt to get the basic idea across: # typed: true class Merchant extend T::Sig sig {returns(String)} attr_reader :name si…

This syntax is horrible. I'm surprised they didn't just copy Python's typing syntax.

Re: RBS, Ruby’s new type signature language

#147

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.

You can run Python type check before runtime at the cost of start time, or better before GIT commit or push (Git Hooks)

Re: RBS, Ruby’s new type signature language

#148

Earlier quoted context omitted.

I don't use ruby, I am genuinely interested - why is it great? I'm assuming if it were ever allowed, it would be a use-at-will feature and wouldn't affect anyone who didn't use it. Typescript has probably doubled if not more my speed and accuracy since I've adopted it - yet I still do plenty of things in normal javascript. These days I'm usually unhappy when something does not have typings because it can make it terr…

The philosophical argument in the Ruby community is basically that Ruby is not a statically typed language, period. And a strong contingent, myself included, do not want a hybrid world where type annotations are optional, spattering redundancies all over our syntax. Mostly because I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking and de…

The best type definition languages do not introduce redundancies. They describe information that is not already in the implementation itself.

Re: RBS, Ruby’s new type signature language

#149
post #62

Earlier quoted context omitted.

Yep. A good IDE to a first approximation doesn't allow compilation errors to occur because you are auto-completing everything, including symbol completion based on the type at cursor, etc. Jetbrains is a wonderful company.

Since the advent of LSP, I think the value proposition of a full featured IDE has been greatly diminished. For example, I used to use Intellij for Scala but recently switched to Emacs+Metals and haven't really missed anything. In fact, it's probably an even better editing experience. Intellij still has better refactoring (though I don't use it much), and the integrated debugger and database viewer are really nice. I'…

I wish I had had your luck with language servers. They are fantastic when they work but in my experience configuring them is finicky and difficult, particularly with Emacs. I have also run into problems where the server crashes and does not restart itself, so the IDE functionality in my editor will just silently break and I have to go fix it. JetBrains still dominates the market for IDEs that work out of the box, and I still don't know of any LSPs that can even remotely compete with the sophistication of their static analysis tools and such.

Re: RBS, Ruby’s new type signature language

#150

I likely am missing some context, but the comparison to TypeScript's ".d.ts" files seems misplaced. This is a type signature language, but it does not seem to be a type checker. The comparison to .d.ts files then seems bizarre because that is helpful for language servers¹ to consume types, but there's no proof that say, the implementation matches the type specification. TypeScript declaration files declare what the t…

The comparison to ".d.ts" seems apt since both are languages/grammars focused solely on declaring types. How they are interpreted is a different matter of course. TypeScript assumes they are strict declarations of the JavaScript code, while Steep/Sorbet will use the declarations to type check your code.

In your example you would get a type checker error.

Post reply on HN