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

231–240 of 340 posts

Re: RBS, Ruby’s new type signature language

#231

Post by cutler »

jolux wrote: post #144
mumblemumble wrote: post #140

Earlier quoted context omitted.

> And it slows development down. This can depend really heavily on what you mean by "development." If it's just getting the first version banged out, sure. If it includes coming back to code a couple years later in order to incorporate a new business requirement, having that documentation present can be a really big deal. 2 seconds spent typing out a type hint now might, down the line, save several minutes on average…

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

Try Clojure for the ultimate programming in data experience. In Clojure code is data so everything is just data.

Re: RBS, Ruby’s new type signature language

#232

Post by rudolph9 »

Polylactic_acid wrote: post #228
hrktb wrote: post #171

Earlier quoted context omitted.

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.

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

Re: RBS, Ruby’s new type signature language

#233

Post by TylerE »

jrochkind1 wrote: post #205
rattray wrote: post #198

Earlier quoted context omitted.

> 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 arg…

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.

Re: RBS, Ruby’s new type signature language

#234

Post by darkdimius »

baweaver wrote: post #70
riffraff wrote: post #38

Earlier quoted context omitted.

AFAIU sorbet can consume RBS files, and probably produce them from libraries that use it. But other type checkers could be implemented relying on the same information.

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

RBI is limited by ruby syntax and thus isn't as nice, but has good semantics and support inline annotations. And has been tried on hundreds of real codebases including those with dozens of millions lines of code.

We'll need to gather benefits of both on our way forward.

Re: RBS, Ruby’s new type signature language

#235

Post by jolux »

cutler wrote: post #231
jolux wrote: post #144

Earlier quoted context omitted.

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

Try Clojure for the ultimate programming in data experience. In Clojure code is data so everything is just data.

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

Re: RBS, Ruby’s new type signature language

#236

Post by mumblemumble »

jolux wrote: post #226
mumblemumble wrote: post #214

Earlier quoted context omitted.

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.

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

Re: RBS, Ruby’s new type signature language

#237

Post by iso8859-1 »

MaxBarraclough wrote: post #104
vidarh wrote: post #86

The article's use of "typed vs untypes" instead of "statically vs dynamically typed" is really unfortunate, and doesn't exactly inspire confidence.

Indeed. To expand on your point: yep, it's incorrect. An untyped language is a language in which there is no concept of type. Assembly languages tend to be untyped. Forth is untyped. The Ruby and Python languages do have the concept of type, it's just that they're dynamically typed, not statically typed. They check types at runtime.

But when you have things like "duck typing", don't you think "they check types at runtime" becomes less meaningful? The majority of functions written in Python, even the ones that have type annotations, do not effectively have "assert isinstance(...)" in the program text below their signature, which is what I'd expect after reading "check types at runtime".

Also, Python now has (in its stdlib!) things like typing.Protocol, which is almost exclusively checked at type checking time. So if such a thing exists, and you still say "types are checked at runtime", isn't that confusing?

Re: RBS, Ruby’s new type signature language

#238

Post by digitaltrees »

dragonwriter wrote: post #221
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).

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

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.

Re: RBS, Ruby’s new type signature language

#239

Post by mumblemumble »

jolux wrote: post #235
cutler wrote: post #231

Earlier quoted context omitted.

Try Clojure for the ultimate programming in data experience. In Clojure code is data so everything is just data.

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.

Re: RBS, Ruby’s new type signature language

#240

Post by dragonwriter »

digitaltrees wrote: post #238
dragonwriter wrote: post #221

Earlier quoted context omitted.

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

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.
Post reply on HN