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

221–230 of 340 posts

Re: RBS, Ruby’s new type signature language

#221

Post by dragonwriter »

avodonosov wrote: post #197
avolcano wrote: post #9

Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :) It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a .d.ts file - as that allows for different type checking implementations to use the same system under the hood. This was a big problem for Flow, and why it lost the fight as soon as Typ…

It must be a very easy next step to allow type declaration inline with the code, for example as comments of special format, or maybe some meta-fields / annotations (I'm not a rubyist so don't know whether the language allows associating custom meta information with program elements).

> It must be a very easy next step to allow type declaration inline with the code

Updating Ruby’s already notoriously complex syntax to support type annotations while keeping existing Ruby code valid with it's existing semantics is...not a very easy step, I suspect.

Annotations in documentation is a more viable way of integrating type definitions into program source files.

Re: RBS, Ruby’s new type signature language

#222

Post by loktarogar »

kgraves wrote: post #216
loktarogar wrote: post #190

Earlier quoted context omitted.

I touched on performance later on - and it's the primary reason I use crystal. I mean more than the language's API changes often.

stability of the language is their next goal.

sure, and I hope it gets there soon, but it's not there yet, which was the real point of my answer to "why not just use Crystal"

Re: RBS, Ruby’s new type signature language

#223

Post by dragonwriter »

chc wrote: post #217
avodonosov wrote: post #197

Earlier quoted context omitted.

It must be a very easy next step to allow type declaration inline with the code, for example as comments of special format, or maybe some meta-fields / annotations (I'm not a rubyist so don't know whether the language allows associating custom meta information with program elements).

I mean, the most obvious solution would just be to unify Ruby's basic syntax with the RBS syntax shown in the OP. This format already looks like a Ruby class definition with the method bodies omitted and some simple "-> type" and ": type" syntax added. I think that's why people find the separation confusing.

> This format already looks like a Ruby class definition with the method bodies omitted and some simple "-> type" and ": type" syntax added

The thing is that much of it is perfectly valid Ruby code with wildly different semantics already, so, no, without breaking a lot, you can't unify it with Ruby syntax.

Re: RBS, Ruby’s new type signature language

#224

Post by ysavir »

fimbulvetr wrote: post #101
jakearmitage wrote: post #81

Earlier quoted context omitted.

Which is great.

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…

It's great because Ruby is an Object-Oriented Programming language. Just saying that is an understatement; Ruby lives and breathes Object Oriented philosophies. It was made for them.

The conflict here is that object oriented philosophies aren't actually about objects. They're about communication between objects. The messaging between objects. As per Alan Kay himself:

> I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging".

The goal of object oriented design is to focus on the communication between objects, not the objects themselves. Part of that is that the type of object receiving the message doesn't matter so long as it understands the message and knows how to respond. If the object looks like a duck, swims like a duck, and quacks like a duck, that's good enough--even if the duck turns out to be a chicken with an identity crises. It understood the message and responded, and that's all we want in object oriented programming, objects that can communicate with each other.

Adding type checking flies in the face of this philosophy. Instead of type being irrelevant as long as the receiver of a message can understand that message, suddenly it's front and center. The code will accept or reject objects based on their type even if they're fully capable of upholding their end of the conversation.

Type-less-ness is core to Ruby. But some people may still prefer to include typing. We all want to use the tools and practices that best enable us to deliver, so that's a fair want. But since Ruby as a philosophy doesn't care about type, it's important to maintain type checking as an accessory to the language, not a feature of it. Something that can be layered on top of the Ruby language for those that want it, but that can be ignored by those don't.

Re: RBS, Ruby’s new type signature language

#225

Post by captn3m0 »

ric2b wrote: post #208
sparker72678 wrote: post #125

Earlier quoted context omitted.

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?

PHP has a strict typing mode: https://www.brainbell.com/php/strict-type.html

Re: RBS, Ruby’s new type signature language

#226

Post by jolux »

mumblemumble wrote: post #214
dropofwill wrote: post #199

Earlier quoted context omitted.

I'm skeptical of Postel's law, if you deviate from the spec how can the meaning be clear? It seems to me like you would have to go out of your way to implement a buggy version of the spec? A personal example of this was Httpd used to accept standard headers with spaces instead of dashes, this leads to strange behavior if you accidentally include both. So they decided to stop doing that in a major version. This major…

That's definitely a concern, but it's also way outside of what I was talking about. I would also expect any JSON parser, even one in a dynamic language, to fail on JSON that is straight-up malformed. And ambiguous formats are always bad news. I'm talking about situations where the JSON is formatted fine, it's just that some field wasn't specified, so then the entire input gets rejected. Even though there was zero nee…

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.

Re: RBS, Ruby’s new type signature language

#227

Post by cutler »

ric2b wrote: post #184
avolcano wrote: post #9

Didn't realize Square was interested in Ruby type checking, just like their competitors over at Stripe. Lots of money riding on Ruby, I guess :) It does seem useful to have a _standard_ for type definitions - RBS as the equivalent to a .d.ts file - as that allows for different type checking implementations to use the same system under the hood. This was a big problem for Flow, and why it lost the fight as soon as Typ…

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

Re: RBS, Ruby’s new type signature language

#228

Post by Polylactic_acid »

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.

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.

Re: RBS, Ruby’s new type signature language

#229

Post by Polylactic_acid »

dragonwriter wrote: post #206
jrochkind1 wrote: post #191

Earlier quoted context omitted.

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.

I expect most ruby projects only have rails as its core dependency with all other gems being small utility libraries that can be easily updated and replaced. Python gets used for such a wide variety of things.

Re: RBS, Ruby’s new type signature language

#230

Post by cutler »

ysavir wrote: post #224
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…

It's great because Ruby is an Object-Oriented Programming language. Just saying that is an understatement; Ruby lives and breathes Object Oriented philosophies. It was made for them. The conflict here is that object oriented philosophies aren't actually about objects. They're about communication between objects. The messaging between objects. As per Alan Kay himself: > I'm sorry that I long ago coined the term "objec…

Bravo. Let dynamic languages be dynamic. Why does every *damn language have to approximate Java in the long run? PHP is nothing more than pseudo-Java and Javascript is heading in the same direction now classes have become firmly-established. At least there's still Clojure.
Post reply on HN