Live data from Hacker News

RBS, Ruby’s new type signature language

developer.squareup.com

171–180 of 340 posts

Re: RBS, Ruby’s new type signature language

#171

Earlier quoted context omitted.

I can well imagine that it might be because ruby's formal syntax is already utterly bonkers, and the thought of adding types to it in any usable fashion gave someone a seizure.

Haven't used ruby in years for the typical reasons people move away from it (performance, strong types, GVL, etc.) but syntax is #1 reason I like programming in Ruby. I did mostly ruby for about 5 years and really grew to love it! It may seem bonkers at first but quite enjoyable once you understand it. Now nearly 4 years later of mostly javascript, golang, python, haskell I still regularly stop and think to my self h…

I read parent’s “bonkers” in a positive way.

Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name: String)“. In ruby it’s of course already taken, in no small part because there are 3 or 4 different ways to declare hash parameters.

I’d imagine most decent syntax candidates had similar issues, due to ruby’s syntax versatility.

Re: RBS, Ruby’s new type signature language

#172

Earlier quoted context omitted.

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.

Have you ever worked with a language that has header files (C/C++) or a language that can use them optionally (Ocaml)? In practice, keeping the files in sync isn’t difficult. In fact, it ends up being better (for me) in terms of readability, because I can look up the type definitions in one place, store them as context, and then read code that isn’t littered with type annotations. Type annotations add quite a bit of noise to code. I think that’s what Matz is going for here. You need to be able to keep the readability of Ruby, which he’s dedicated his life to.

Re: RBS, Ruby’s new type signature language

#173
post #146

Earlier quoted context omitted.

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.

[deleted]

Re: RBS, Ruby’s new type signature language

#174

Earlier quoted context omitted.

How do you even type local variables?

Why would you need to? Edit: Like, seriously. Either the local var is populated by something coming in externally (which is then typable) or, unless your code is too complex / large, it should be easy to see everywhere it's used, and then why would you need that additional typing info?

Because when you see the benefit of type annotations (I’m not saying that’s objective, just if you do go that route) you want to add type information to as much as possible. Leaving them off because you want to is one thing. Not being able to is an unnecessary limitation.

Re: RBS, Ruby’s new type signature language

#175

Earlier quoted context omitted.

I'm not familiar with Ruby at all, but presumably it'd be possible to at least generate stubbed out definition RBS files with type inference.

It is, and checkers like Steep and Sorbet can infer these types. We're currently playing with the idea of deriving from documentation like YARDoc as well.

https://github.com/AaronC81/sord is one attempt at this

Re: RBS, Ruby’s new type signature language

#176

Earlier quoted context omitted.

I can well imagine that it might be because ruby's formal syntax is already utterly bonkers, and the thought of adding types to it in any usable fashion gave someone a seizure.

Haven't used ruby in years for the typical reasons people move away from it (performance, strong types, GVL, etc.) but syntax is #1 reason I like programming in Ruby. I did mostly ruby for about 5 years and really grew to love it! It may seem bonkers at first but quite enjoyable once you understand it. Now nearly 4 years later of mostly javascript, golang, python, haskell I still regularly stop and think to my self h…

Crystal [1] is a pretty nice ruby like language with types and it is up there with Go/Rust for runtime performance.

[1] https://crystal-lang.org/

Re: RBS, Ruby’s new type signature language

#178
post #169

Earlier quoted context omitted.

Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. > "Whether large enterprise codebases will standardize on requiring type signatures is a different matter" Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.

>Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.

My biggest complaints all center around the intersection of custom types with protocols and extensions, especially when trying to get a generic approach to something working.

Re: RBS, Ruby’s new type signature language

#179

As an avid Rubyist I have no interest in introducing types into a dynamic language. I would just rather use C# or Java. I never understood why people are trying to make a round peg fit in a square hole.

Massive code bases that are difficult to maintain and refactor. It’s a cheaper effort to add types to that code.
Post reply on HN