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

161–170 of 340 posts

Re: RBS, Ruby’s new type signature language

#161

Post by mumblemumble »

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

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 up-front, too. Even the bits you don't actually need to look at in order to accomplish the job at hand. IMO, that approach tends to mean creating a lot of unnecessary work for oneself. It also makes it harder to obey Postel's law.

(The corollary to that last bit is that it is also possible for static typing to create bugs.)

Re: RBS, Ruby’s new type signature language

#162

Post by sparker72678 »

jolux wrote: post #155
sparker72678 wrote: post #152

Earlier quoted context omitted.

My point is that imposing a big ass type system on developers as a "solution" to a trivial number of actual problems is overkill. I'm sure there are developer/projects that both enjoy and benefit from static typing and strict type systems of various kinds. I just want Ruby to remain a place for those of us who aren't in those positions.

I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book. However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't th…

Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty.

> "Whether large enterprise codebases will standardize on requiring type signatures is a different matter"

Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.

Re: RBS, Ruby’s new type signature language

#163

Post by rudolph9 »

regularfry wrote: post #53
muglug wrote: post #16

Can someone explain why the types cannot live in Ruby code itself (after an appropriate version bump)? Python 3 incorporated types into the language itself, in a similar way (though non-reified) to PHP. This seems much easier to deal with than requiring two files (.rb and .rbs) to describe a single data structure.

I can well imagine that it might be because ruby's formal syntax is already utterly bonkers, and the thought of adding types to it in any usable fashion gave someone a seizure.

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 how much I miss ruby!

Re: RBS, Ruby’s new type signature language

#164

Post by Conlectus »

cheez wrote: post #146
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…

This syntax is horrible. I'm surprised they didn't just copy Python's typing syntax.

An important limitation here is that it needs to be valid Ruby syntax as well, since this was added without/before official Ruby typing support.

Re: RBS, Ruby’s new type signature language

#165

Post by vemv »

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.

Re: RBS, Ruby’s new type signature language

#166

Post by Trasmatta »

cheez wrote: post #146
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…

This syntax is horrible. I'm surprised they didn't just copy Python's typing syntax.

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.

Re: RBS, Ruby’s new type signature language

#167

Post by frewsxcv »

RangerScience wrote: post #106
heavenlyblue wrote: post #65

Earlier quoted context omitted.

How do you even type local variables?

Why would you need to? Edit: Like, seriously. Either the local var is populated by something coming in externally (which is then typable) or, unless your code is too complex / large, it should be easy to see everywhere it's used, and then why would you need that additional typing info?

If something is untyped in Sorbet, you can give it a type with `T.let`. So if the return value of function `foo` is untyped, but you have a high degree of confidence that it will return a `String`, you can do `ret = T.let(foo, String)`

Re: RBS, Ruby’s new type signature language

#168

Post by jolux »

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…

You can definitely still do this kind of programming in a statically typed language. There are a few ways to go about it.

One way is to treat the JSON as a generic JSON structure, and traverse it manually. Of course, you will have to be explicit about what should happen when children are of different types from what you expect, though this explicitness could just be throwing an exception or ignoring it. Haskell's Aeson and Rust's serde_json both support this, as does .NET's JsonElement type.

Unfortunately, this means you're passing around a lot of objects called something like "JSON" without any information about what they contain at the type level, and as an alternative between that approach and creating domain objects, there are row polymorphic records, which allow you to write functions that accept any record that has certain fields, and also specify that they may also contain other fields which you do not handle. This allows you to program to what you know about the types you're ingesting without having to write a lot of new types.

Re: RBS, Ruby’s new type signature language

#169

Post by jolux »

sparker72678 wrote: post #162
jolux wrote: post #155

Earlier quoted context omitted.

I'm not sure what a "big ass type system" is, and I disagree that the number of actual problems is trivial. However, I'm in no more position to say what Ruby should be than you are, and I'm sorry you're so opposed to static types that even attempting to support them is a minus in your book. However, even with TypeScript ascendant, the vast majority of people programming JavaScript write vanilla dynamic JS. I don't th…

Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty. > "Whether large enterprise codebases will standardize on requiring type signatures is a different matter" Totally agree that there will always be people who value this tradeoff. That's fine, I just want the Ruby I know and love to keep existing.

>Swift's type system is what I have in mind: strict, complex, required, and in my experience, often petty.

I do hear a lot of complaints about Swift's type system. I wonder what the specific problems are, because I do not hear similar complaints about Rust. I wonder if it's the combination of subtyping with a lot of type inference and also a full-on trait system with protocols and extensions and such.

Re: RBS, Ruby’s new type signature language

#170

Post by regularfry »

rudolph9 wrote: post #163
regularfry wrote: post #53

Earlier quoted context omitted.

I can well imagine that it might be because ruby's formal syntax is already utterly bonkers, and the thought of adding types to it in any usable fashion gave someone a seizure.

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…

As an end user, it's amazing. I do have sympathy for the implementers, though.
Post reply on HN