←back to thread

RBS, Ruby’s new type signature language

(developer.squareup.com)
511 points mootrichard | 7 comments | 29 Jul 20 18:04 UTC | HN request time: 0s | source | bottom
Show context
muglug ◴[29 Jul 20 19:15 UTC] No.23990520[source]▶
Can someone explain why the types cannot live in Ruby code itself (after an appropriate version bump)?

Python 3 incorporated types into the language itself, in a similar way (though non-reified) to PHP. This seems much easier to deal with than requiring two files (.rb and .rbs) to describe a single data structure.

replies(4): >>23990918 #>>23990947 #>>23991201 #>>23991455 #
regularfry ◴[29 Jul 20 20:01 UTC] No.23990947[source]▶
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.
replies(1): >>23991741 #
rudolph9 ◴[29 Jul 20 21:23 UTC] No.23991741[source]▶
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 how much I miss ruby!
replies(3): >>23991854 #>>23991856 #>>23991913 #
1. hrktb ◴[29 Jul 20 21:36 UTC] No.23991856[source]▶
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.

replies(3): >>23992665 #>>23993158 #>>23996311 #
2. Polylactic_acid ◴[29 Jul 20 23:24 UTC] No.23992665[source]▶
The worst part of ruby imo is the fact that a hash can have both string and symbol keys. Countless times I have encountered issues where a function takes an options hash and the callers use both string and symbols for the same key depending on which caller it is. I end up calling the function to convert to symbols all the time.
replies(2): >>23992772 #>>23994157 #
3. rudolph9 ◴[29 Jul 20 23:42 UTC] No.23992772[source]▶
Actually, if my memory serves me, a ruby hash can use any object a key! And considering everything in ruby is an object (even the class `Object`) it’s really quite elegant
replies(1): >>23993152 #
4. vlunkr ◴[30 Jul 20 00:42 UTC] No.23993152{3}[source]▶
This seems to be getting downvotes? I don't know why, it's accurate. Anything can be a key in Ruby.
5. Glyptodon ◴[30 Jul 20 00:43 UTC] No.23993158[source]▶
I'm trying to think of any typical chars that don't already mean something and I think at best you'd have to use a pair and even then it would potentially break older code. Very badly offhand something like: `attr_accessor ~:String :name` and `def sing(~:Song song):` seems pretty ugly but borderline feasible on the premise that while ~ and : have meaning in Ruby, it's not super likely that bitwise inverting symbols is common. (I'm sure there more reasons that wouldn't work or isn't great.)

I don't like the separate file thing, but it does seem more challenging than I'd have thought to avoid.

I guess on a tangent Ruby code historically cares a lot more for duck typing so strong typing will be a headache for a lot of stuff.

6. tdeck ◴[30 Jul 20 03:08 UTC] No.23994157[source]▶
This is why ActiveSupport (Rails) has Hash#with_indifferent_access and people use it all over the place.
7. regularfry ◴[30 Jul 20 09:54 UTC] No.23996311[source]▶
I genuinely think that adding `:` as a hash separator was a mistake. Apart from anything else, you get this weird effect where the type of the key in `{"foo": bar}` isn't what you think it is.