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

211–220 of 340 posts

Re: RBS, Ruby’s new type signature language

#211

Post by kgraves »

Thaxll wrote: post #138
kgraves wrote: post #77

Earlier quoted context omitted.

How is Crystal a "half baked language"?

The current state of Crystal is basically a language for PoC during the week-end, it's far from being ready. I could go on about what's wrong with the language but: It's not stable, API change all the time, breaking change all the time, cryptic errors, lot of missing basic features, IDE integration etc ...

> The current state of Crystal is basically a language for PoC during the week-end, it's far from being ready.

That is changing, earlier this year, the Crystal team are working on getting the language stable for 1.0 [0]

Companies are already now using Crystal in production, most recently Nikola Motor Company [1].

Surely they wouldn't choose crystal if it was a 'half baked' language.

[0] https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html

[1] https://manas.tech/blog/2020/02/11/nikola-motor-company/

Re: RBS, Ruby’s new type signature language

#212

Post by ric2b »

wolfadex wrote: post #153
amw-zero wrote: post #49

Earlier quoted context omitted.

I much prefer separate files for type declarations. Or at least the ability to define them separately. Type annotation takes away from readability. I like keeping the types and code separate.

Type annotations aren't inline in all languages. If you're writing Haskell or Elm, as a few examples, then you get static types without having to write them out and if you do write them out they sit above the function that uses them.

I don't think anyone is disappointed that it isn't literally inline, the problem is that it's in separate files.

Re: RBS, Ruby’s new type signature language

#213

Post by vemv »

sixstringtheory wrote: post #204
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/Ge…

One can check that something is a string and not a blank one.

There are two different libraries that do it:

https://github.com/plumatic/schema/blob/ddb54c87dea6926c6d73...

https://github.com/clojure/spec.alpha/blob/eb49d429e85b6878a...

Honestly I highly suspect that many, many "typing" solutions out there are plain ignorant of the whole spectrum of choices one can make, are tend to lean towards Java-like APIs out of that ignorance.

This is not limited to Ruby, I also see it in TypeScript which is very much a contrived system for real-world usages while making little use of JS's dynamism.

Re: RBS, Ruby’s new type signature language

#214

Post by mumblemumble »

dropofwill wrote: post #199
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…

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 need to read the contents of that field in the first place. It just happened to be included in some domain object that gets re-used everywhere, including some other places where the field's contents do matter.

Keep in mind that, when we're dealing with anything that might be transmitted in JSON, thinking that there might be a published spec, and that it manages to accurately cover all these details, is really optimistic. I've honestly never seen it happen in the wild. Oftentimes, any validation rules you might try to impose are guesswork as much as they are anything else. So complaining that a piece of data didn't conform to the spec might not even be a valid thing to do. All you can say for sure is that the data didn't meet the needs of some piece of business logic.

It's not perfect, but it's life. This tension, for example, is at the heart of why proto2 got replaced with proto3, and why using proto3 is strongly encouraged if you're looking to build a robust infrastructure.

Re: RBS, Ruby’s new type signature language

#215

Post by sixstringtheory »

vemv wrote: post #213
sixstringtheory wrote: post #204

Earlier quoted context omitted.

> 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/Ge…

One can check that something is a string and not a blank one. There are two different libraries that do it: https://github.com/plumatic/schema/blob/ddb54c87dea6926c6d73... https://github.com/clojure/spec.alpha/blob/eb49d429e85b6878a... Honestly I highly suspect that many, many "typing" solutions out there are plain ignorant of the whole spectrum of choices one can make, are tend to lean towards Java-like APIs out of…

I'm glad we agree that adding type annotations to code is a good thing. You aren't arguing against that–you are just arguing implementation details. If I'm designing a 5 9s service tasked with processing gigabytes of data every unit time, I don't want to pay the runtime cost of checking the types for every mundane operation like measuring the length of a string.

Re: RBS, Ruby’s new type signature language

#216

Post by kgraves »

loktarogar wrote: post #190
kgraves wrote: post #72

Earlier quoted context omitted.

> Crystal is pretty unstable at the moment (in that it changes often) This had never been my experience, I have a server written fully in crystal running in production serving millions upon millions of requests on heroku and crystal doesn't break a sweat. Quite happy with it so far.

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.

Re: RBS, Ruby’s new type signature language

#217

Post by chc »

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

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.

Re: RBS, Ruby’s new type signature language

#218

Post by vemv »

sixstringtheory wrote: post #215
vemv wrote: post #213

Earlier quoted context omitted.

One can check that something is a string and not a blank one. There are two different libraries that do it: https://github.com/plumatic/schema/blob/ddb54c87dea6926c6d73... https://github.com/clojure/spec.alpha/blob/eb49d429e85b6878a... Honestly I highly suspect that many, many "typing" solutions out there are plain ignorant of the whole spectrum of choices one can make, are tend to lean towards Java-like APIs out of…

I'm glad we agree that adding type annotations to code is a good thing. You aren't arguing against that–you are just arguing implementation details. If I'm designing a 5 9s service tasked with processing gigabytes of data every unit time, I don't want to pay the runtime cost of checking the types for every mundane operation like measuring the length of a string.

Design by contract (which the mentioned libraries excel at) isn't a new thing, and the mentioned one is a solved problem. https://en.wikipedia.org/wiki/Design_by_contract#Performance...

Re: RBS, Ruby’s new type signature language

#219

Post by danudey »

vidarh wrote: post #134
danudey wrote: post #116

Earlier quoted context omitted.

> Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. To answer this (as someone who basically only ever writes in Python): There are a few cases where it's really nice to be able to add type annotations to methods or functions. The most obvious example is API calls; it's nice to be able to say "this needs to be a list, give me a list", and not have to do if not isinstance(var,…

I just worry it's going to be abused, though. E.g. I've worked with more than one Ruby code base where someone did a kind_of? check and threw exceptions if it didn't get what it wanted even though the actual type required was anything that implemented a given method in a reasonable way for no good reason. I hope people keep the type annotations sparse, and allow the tools to infer it unless they're prepared to link l…

I think your own example proves that your concern is moot. If people are going to do stupid stuff, they're going to do it with whatever tools are available to them. Your kind_of misbehavior already happens without type annotations, but now it can be clear to you beforehand what's going to happen.

Re: RBS, Ruby’s new type signature language

#220

Post by dragonwriter »

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…

> On the other hand, RBS as hand-written seems rather dangerous, to me. Nothing wrong with using them to define previously-untyped external code, as long as you know the caveats, but I think you really want to have definitions generated from your code.

That’s sounds like what type-profiler, mentioned in the article, is for; it's an experimental project which,if successful, seems destined to be part of Ruby’s bundled command line tooling, for generating type signatures from code.

If you mean you want type signatures embedded in code source files rather than in separate files, they seem to be taken a documentation-annotation approach, with YARD documentation format expressly called out as a mechanism to bed typing in source files. That's probably cleaner than further cluttering Ruby’s syntax with annotations.

> Given that Ruby 3 was supposed to "support type checking," I'm surprised that it does not seem to have syntax for type definitions in code

The support seems to be that, at a minimum, that it will have a standard for type definitions and provide them for Core and Stdlib and have command line tooling for working with type definitions. Which is, I would say, significante support.

Post reply on HN