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

191–200 of 340 posts

Re: RBS, Ruby’s new type signature language

#191

Post by jrochkind1 »

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.

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 old version of the language. Ruby adds new features including syntax that won't properly parse in old interpreters all the time. It's not clear to me why inline type definitions couldn't be such.

Re: RBS, Ruby’s new type signature language

#192

Post by loktarogar »

3by7 wrote: post #69
loktarogar wrote: post #43

Earlier quoted context omitted.

Crystal is pretty unstable at the moment (in that it changes often). I have a very small project in crystal (discord bot with only a couple of commands that CRUDs a database). Every time I deploy to heroku, if heroku updated crystal, the bot breaks. I have to spend an hour determining what broke. The language changes so often that either I update with heroku or I can't use any newer libraries for development. And the…

> Every time I deploy to heroku, if heroku updated crystal, the bot breaks Have you tried adding a `.crystal-version` file as described in the buildpack's README? https://github.com/crystal-lang/heroku-buildpack-crystal#cry...

Yeah, the issue is more that I can either keep Crystal updated and use all libraries, or keep it frozen and be restricted in what I use. It's not mature enough yet to be able to lock it down and have more or less Crystal's entire shard collection available to me, like I can do in Ruby. Reminds me more of Ruby a decade ago with 1.8.7 and 1.9.2 and 2.0 (which is fine for it to be at, esp for an evolving language, but it's not "there yet" to be a replacement for Ruby)

One incident that stands out is that certain Postgres support was only available in the latest version of a shard, which required the latest version of Crystal, which wasn't compatible with 3 of the other shards I was using.

Re: RBS, Ruby’s new type signature language

#193

Post by jrochkind1 »

freedomben wrote: post #31

I'm not thrilled about the separate files with the type information but I completely understand why they did it, and if it were my choice I might make the same one. I don't like the comparison with TypeScript `.d.ts` files however, because TS still lets you do types inline in the code. I haven't seen it mentioned anywhere that this won't be supported by Ruby 3. Does anybody know if Ruby 3 will also support inline typ…

If you completely understand why they did it, can you explain it to me?

> Does anybody know if Ruby 3 will also support inline type information or will the header RBS files be required?

Wait, what are we talking about? I thought this was the decision you said you completely understood, that the type information is in separate .rbs files. Isn't ruby 3 what we're talking about?

Re: RBS, Ruby’s new type signature language

#194

Post by Trasmatta »

cheez wrote: post #182
Trasmatta wrote: post #166

Earlier quoted context omitted.

I believe one of their guiding principles was that they wanted all the syntax to be valid Ruby, because they did not want it to become a separate Ruby interpreter. So they were pretty limited in the syntax available to them.

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.

Re: RBS, Ruby’s new type signature language

#195

Post by joelbluminator »

hombre_fatal wrote: post #75
rch wrote: post #42

Earlier quoted context omitted.

> still not there And never will be.

Not sure what you're saying. What are places where Node isn't caught up to Ruby and can never catch up to Ruby? Ruby on Rails seems like a kneejerk response, but then again it doesn't exist because nobody really wants it, not for technical reasons. For example, Python has all the ML/math stuff. Nothing comes to mind for Ruby.

No one really wants it other than the guys who use Sails I guess...or is the name just a coincidence?

Re: RBS, Ruby’s new type signature language

#196

Post by lmm »

sparker72678 wrote: post #120
zeptonix wrote: post #95

Earlier quoted context omitted.

Yeah, it is. I'm having a really hard time understanding this "I need types forced down my throat" and "I like typing 3x as much as I would otherwise need to" and "yes, I want half my screen obscured by the types of everything I'm doing, not the actual code" and the "adding types now means bugs are impossible" mass cult hysteria that's running so rampant. Typing very occasionally prevents bugs that are generally easy…

A-fucking-men. In the course of my job I write Swift for iOS and Ruby for server APIs and our web-based UIs. Type issues are about 0% of my Ruby bugs, but dealing with all the damn type requirements in Swift regularly takes dozens of minutes to track down when some weird esoteric error message pops up. And God help you if you try to use generics. If you want strong typing, then good for you. Just pick a language that…

> Type issues are about 0% of my Ruby bugs

Doubt.

In my experience at least 70% of bugs are ones that you'd catch by using types - things like x instead of y, possibly-empty list instead of known-nonempty list, user ID instead of group ID. Logic errors that couldn't be caught by typing do exist, but they're very much the minority.

Re: RBS, Ruby’s new type signature language

#197

Post by avodonosov »

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).

Re: RBS, Ruby’s new type signature language

#198

Post by rattray »

jrochkind1 wrote: post #187
rattray wrote: post #100

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…

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 arguments.

Re: RBS, Ruby’s new type signature language

#199

Post by dropofwill »

mumblemumble wrote: post #161
jolux wrote: post #144

Earlier quoted context omitted.

I'm curious what you mean by "data-level programming."

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…

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 version was opaquely included by ops accidentally into our base images. This lead to a very long day of debugging on our end.

Point is, by being liberal with what you accept you create ambiguity, which you may not totally understand at the time. By putting that out into the wild you basically are forced to keep this ambiguous, undocumented spec alive or you no doubt will end up breaking some client.

Re: RBS, Ruby’s new type signature language

#200

Post by rosywoozlechan »

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…

> Typescript has probably doubled if not more my speed and accuracy since I've adopted it

TypeScript hasn't ever done anything for me than give me 3rd party dependency integration headaches. I love strongly typed languages and compile time checking, but TypeScript has never seemed worth the trade off due to its broken interoperability with normal JavaScript and the terrible state of crowd sourced typedefs. I'm either fighting some badly defined third party typedef, spending a lot of time creating typedefs myself or dealing with a version issue because the typedef isn't compatible with the version of the library I'm using.

When I use JavaScript I hardly ever run into issues that static typing would have prevented and I have zero TypeScript issues.

Honestly how has it improved the speed at which you get things done? Were you just constantly running into JavaScript bugs due to the lack of typing?

Post reply on HN