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

201–210 of 340 posts

Re: RBS, Ruby’s new type signature language

#201

Post by jrochkind1 »

Lammy wrote: 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

note that syntax isn't actually new in ruby 2.7 or 3.0 at all. It's been around since ruby 2.0 in fact (Feb 2013). (keyword arguments had to be declared with default values until ruby 2.1, Dec 2013).

What ruby 2.7/3.0 do is rationalize some really weird counter-intuitive and ambiguous edge cases related to passing a Hash arg expecting it to be invoked as if it were keyword args. But it's a change in semantics, not syntax. The keyword argument syntax, keyword arguments with colons, in both method definitions and invocations, has been around for years, unchanged.

Re: RBS, Ruby’s new type signature language

#202

Post by cheez »

Trasmatta wrote: post #194
cheez wrote: post #182

Earlier quoted context omitted.

I'm not sure a separate interpreter is necessary but a preprocessor could remove the notations perhaps.

I believe they don't want to just strip out the annotations because Sorbet also does run time type checking. So to get all the features they wanted, they had to either write a new interpreter or use valid Ruby.

OK, take non-ugly syntax, translate to ugly syntax.

Re: RBS, Ruby’s new type signature language

#203

Post by dragonwriter »

Jabbles wrote: post #103
baweaver wrote: post #98

Earlier quoted context omitted.

Pretty much. Matz is very sensitive to breaking the language in any way with the Ruby 3 upgrade, which brought up the true keyword argument hard-break and [likely got that pushed back]( https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argume... ). RBS and type files on the side were really hotly debated for a while and the core team settled on this as a way to not break the existing parser among other reasons. W…

His view is probably informed by the Python 2->3 experience.

And also the Ruby 1.8->1.9 experience.

Re: RBS, Ruby’s new type signature language

#204

Post by sixstringtheory »

vemv wrote: post #165

Checking that something is a String is pretty weak and uninteresting. How about checking that a given string is non-blank? That tends to fully leverage Ruby's dynamic nature. But then again people are overly fixated with compile-time, Java-like signatures. See clojure.spec for a success story.

> How about checking that a given string is non-blank?

Because when you try to do this with some object that doesn't have a "length" or "empty?" method, your application crashes.

    irb(main):013:0> a = 1
        => 1
    irb(main):014:0> b = "1"
        => "1"
    irb(main):015:0> b.length
        => 1
    irb(main):016:0> a.length
        Traceback (most recent call last):
            4: from /usr/bin/irb:23:in `'
            3: from /usr/bin/irb:23:in `load'
            2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `'
            1: from (irb):16
        NoMethodError (undefined method `length' for 1:Integer)
    irb(main):017:0> b.empty?
        => false
    irb(main):018:0> a.empty?
        Traceback (most recent call last):
            4: from /usr/bin/irb:23:in `'
            3: from /usr/bin/irb:23:in `load'
            2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `'
            1: from (irb):18
        NoMethodError (undefined method `empty?' for 1:Integer)
This is why people want a way to know if something they think is a String is actually a String, without risking data loss and outages at runtime.

I think it's rude to dismiss people asking for this as "fixated," and furthermore it could be no less fairly used against people who show up to these debates beating their own drum against it.

Re: RBS, Ruby’s new type signature language

#205

Post by jrochkind1 »

rattray wrote: post #198
jrochkind1 wrote: post #187

Earlier quoted context omitted.

OK, but if we're going to have .rbs, why not just modify the ruby syntax to allow .rbs-style types inline? Especially becuase .rbs already looks like class and method definitions without the bodies. So... just add the bodies. class Merchant attr_reader token: String attr_reader name: String attr_reader employees: Array[Employee] def initialize(token: String, name: String) -> void # actual method body end def each_emp…

> why not just modify the ruby syntax The Ruby syntax is too complicated to allow for changes like this to be backwards-compatible. For example, `attr_reader token: String` is valid ruby today – that's the same as `attr_reader(:token => String)` which somebody might be doing in the wild, since you can override `def self.attr_reader`. Similarly, `def initialize(token: String` clashes with the definition of keyword arg…

doh! good point.

I am not able to spin that into "And besides it's better to force it to be in two files anyway!", I don't think it is, but I guess it's not so easy to do different.

Re: RBS, Ruby’s new type signature language

#206

Post by dragonwriter »

jrochkind1 wrote: post #191
Jabbles wrote: post #103

Earlier quoted context omitted.

His view is probably informed by the Python 2->3 experience.

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.

Re: RBS, Ruby’s new type signature language

#207

Post by [deleted] »

jolux wrote: post #168
mumblemumble wrote: post #161

Earlier quoted context omitted.

Leaving the data in basic data formats. For example, JSON describes a logical structure of nested lists and dictionaries. If you were doing data-level programming, you would just map the JSON into actual nested lists of dictionaries and get on about your business. The alternative, which is more common in static languages like Java, is to transform it all into some set of domain model objects, and probably validate it…

You can definitely still do this kind of programming in a statically typed language. There are a few ways to go about it. One way is to treat the JSON as a generic JSON structure, and traverse it manually. Of course, you will have to be explicit about what should happen when children are of different types from what you expect, though this explicitness could just be throwing an exception or ignoring it. Haskell's Aes…

[deleted]

Re: RBS, Ruby’s new type signature language

#208

Post by ric2b »

sparker72678 wrote: post #125
fimbulvetr wrote: post #101

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…

> I see that as a step in the direction of some kind of "strict" mode that will ultimately enforce type annotations and type-checking

Ruby is not the first or the second or even the third dynamic language that has added static type checking support, has this _ever_ happened?

Re: RBS, Ruby’s new type signature language

#209

Post by hombre_fatal »

RangerScience wrote: post #106
heavenlyblue wrote: post #65

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?

One big use-case of types is the sanity-check that the value is what you think it is.

A classic example of where I might have an inline type annotation in Rust is when I'm doing a non-trivial chain of Future/Result combinators in the middle of a function. It doesn't take much code for your understanding to desync from reality. Annotating "Result" inline both documents to others what this intermediate value is but also creates better, local errors as the chain is modified.

Complex stuff does generally get factored out into functions, but at the same time, it's nice when you're the one who decides when it makes sense to extract code rather than a limitation of the typing syntax. Those things don't always line up.

Re: RBS, Ruby’s new type signature language

#210

Post by RangerScience »

lovetocode wrote: post #177

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.

FYI: Try Scala. IMO it feels a lot like working in Ruby.
Post reply on HN