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

241–250 of 340 posts

Re: RBS, Ruby’s new type signature language

#241

Post by jolux »

mumblemumble wrote: post #239
jolux wrote: post #235

Earlier quoted context omitted.

I have tried programming in Clojure :) I just prefer strongly typed languages.

Clojure is strongly typed. I think you mean statically typed. They're orthogonal concerns. C is statically and weakly typed. Clojure is dynamically and strongly typed. PHP is dynamically and weakly typed. Haskell is statically and strongly typed. Java, as the most design-by-committe language ever, manages to be a mix of all four.

"Strong" typing doesn't mean much of anything and I generally try to avoid using it but slipped up here. When I do use it, I use it as a synonym for static languages with expressive type systems. I prefer statically typed languages.

Re: RBS, Ruby’s new type signature language

#242

Post by jolux »

mumblemumble wrote: post #236
jolux wrote: post #226

Earlier quoted context omitted.

There are huge debates at Google internally over required vs optional in proto2 and proto3. Beyond that I think you’re operating from a misconception about JSON parsing in static languages. There’s no requirement to convert to domain objects and reject data that doesn’t fit on a triviality, you’re just required to specify explicitly what happens when you encounter unexpected structure or data.

Sorry if I wasn't being clear. I'm not saying that's the only way it can work in static languages. I'm saying that that's the way it tends to work out in practice, because the ergonomics of most popular static languages tend to discourage a less brittle approach. Whereas the ergonomics of popular dynamic languages tend to favor an approach that I find, for this specific purpose, to be both less verbose and more robus…

What is the difference in approach between these? I've programmed extensively in dynamic and static languages, and don't understand what you're talking about. Less verbose, I might concede. More robust though, I need some more evidence.

Re: RBS, Ruby’s new type signature language

#243

Post by osdiab »

dragonwriter wrote: post #240
digitaltrees wrote: post #238

Earlier quoted context omitted.

This is the first I have ever heard of ruby syntax as notoriously complex. If anything it’s usually the opposite. I would love to read why people say that about ruby.

Ruby syntax is designed to be easy to use and flexible for humans; the decisions taken in pursuit of that makes the actual syntax itself quite complex and difficult to parse and, more to the current point, difficult to modify without breaking things that are currently valid Ruby.

Yeah, there are so many alternate syntaxes, shortcuts, and ambiguous statements in Ruby; just reading through Matz’s reference book on Ruby was a trip for me.

Re: RBS, Ruby’s new type signature language

#244

Post by dragonwriter »

TylerE wrote: post #233
jrochkind1 wrote: post #205

Earlier quoted context omitted.

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.

Header files suck. Anything is better than a separate file.

> Anything is better than a separate file.

I dunno. Massive breakages of backward compatibility in an established language may not be better than that.

Re: RBS, Ruby’s new type signature language

#245

Post by baweaver »

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…

That's definitely fair, and probably a large reason why they're so paranoid about repeating that.

Re: RBS, Ruby’s new type signature language

#246

Post by baweaver »

darkdimius wrote: post #234
baweaver wrote: post #70

Earlier quoted context omitted.

That's correct. Sorbet currently uses RBI but after meeting with core they standardized on RBS and are migrating to present a more unified front and enable easier development of type checking libraries on top of it. Very little of this will need to be written by hand. The underlying tech is pretty decent at guessing types, the idea is that if it's not quite specific enough you adjust it, but it should otherwise be tr…

(One of core devs on Sorbet) Agreed. But don't read too much in RBS details yet. RBI is currently very early and will need to change substantially learning from experience of actually typechecking real codebases. Stripe and Shopify are helping with this. RBS has better syntax, but has features that don't have clear semantics or feasible implementation. And doesn't support inline annotations that are necessary in prac…

Agreed. Currently at Square so watching some of this.

The best path forward will be a lot of discussion, especially around learnings with production codebases where possible.

Personally I prefer inline annotations, but want to explore the possibilities of both and see what comes of it. I've written on Sorbet in the past and have used it on a few toy projects.

Also working on some analysis documentation comparing the two if you'd be interested in chatting later. Feel free to DM @keystonelemur on Twitter.

Re: RBS, Ruby’s new type signature language

#247

Post by vlunkr »

rudolph9 wrote: post #232
Polylactic_acid wrote: post #228

Earlier quoted context omitted.

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.

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

This seems to be getting downvotes? I don't know why, it's accurate. Anything can be a key in Ruby.

Re: RBS, Ruby’s new type signature language

#248

Post by Glyptodon »

hrktb wrote: post #171
rudolph9 wrote: post #163

Earlier quoted context omitted.

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.

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.

Re: RBS, Ruby’s new type signature language

#249

Post by derwiki »

cutler wrote: post #227
ric2b wrote: post #184

Earlier quoted context omitted.

> I'm surprised that it does not seem to have syntax for type definitions in code This is a big disappointment to me, one of the main advantages of static typing is that it can make code much easier to understand when types are added to non-obvious method parameters.

Surely a good IDE such as RubyMine would be able to display the type in reponse to, say, a mouseover?

RubyMine tries but it certainly works less well than PyCharm and GoLand.

Re: RBS, Ruby’s new type signature language

#250

Post by etxm »

dragonwriter wrote: post #244
TylerE wrote: post #233

Earlier quoted context omitted.

Header files suck. Anything is better than a separate file.

> Anything is better than a separate file. I dunno. Massive breakages of backward compatibility in an established language may not be better than that.

It is a major version change, right? It seems like the best time to introduce some breaking changes for the betterment of the language.
Post reply on HN