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

111–120 of 340 posts

Re: RBS, Ruby’s new type signature language

#111

Post by julvo »

3pt14159 wrote: post #96
swagonomixxx wrote: post #85

I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language. I much prefer the Python 3+ approach of type annotations in source code. I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.…

This is why I do not like mypy or types in Python other than dataclasses. If I'm going to type the damn thing I better be getting performance ala cython. Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. Ruby would do far better to fix the bloody `and` vs `&&` issue (it should just be `and` and it should work like `&&`) and strings should be immutable by default with a special…

> Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top

Probably using the languages for the ecosystem (e.g. Python for scientific computing or ML and ruby for ruby on rails) but still wanting to benefit from type checking

Re: RBS, Ruby’s new type signature language

#113

Post by rattray »

heavenlyblue wrote: post #65
setpatchaddress wrote: post #52

I'm really puzzled by the decision to use a separate file for this. The stated justification ("it doesn't require changing Ruby code") doesn't make sense, and my personal experience with languages with external type specifications is strongly negative. It's an unbelievable pain to keep multiple interface files in sync over time. `.h` files are not something to emulate! External interfaces should be generated by tools…

How do you even type local variables?

I mentioned elsewhere that Sorbet (an implementation) allows inline type definitions. Its syntax for local variables is this:

    def foo
      username = T.let("heavenlyblue", String)
    end
It's a little clunky but gets the job done, and in practice it's quite rare that you need to type a local variable.

However, more important to have in the body of a program is tools for casting and asserting types, like these:

    T.assert_type(foo, String)
    T.cast(foo, String)
    T.must(foo) # assures the compiler foo is not nil
    T.unsafe(foo) # the equivalent of a TS `any` cast
Docs at https://sorbet.org/docs/type-assertions

I'm not sure how tools that use RBS without inline syntax will handle these situations, but to be honest I expect the community to adopt Sorbet in practice anyway. It's very fast and battle-hardened in production at Stripe and several other large companies.

Disclaimer, again: former Stripe employee.

Re: RBS, Ruby’s new type signature language

#115

Post by baweaver »

rattray wrote: post #100
setpatchaddress wrote: post #52

I'm really puzzled by the decision to use a separate file for this. The stated justification ("it doesn't require changing Ruby code") doesn't make sense, and my personal experience with languages with external type specifications is strongly negative. It's an unbelievable pain to keep multiple interface files in sync over time. `.h` files are not something to emulate! External interfaces should be generated by tools…

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…

Sorbet was written in C++ and is a great piece of work, Stripe did a great job with it. It does have some issues as soon as someone gets into the magic weeds with metaprogramming like Rails does.

Disclaimer: Working at Square, have friends at Stripe, enjoy both type checkers.

Re: RBS, Ruby’s new type signature language

#116

Post by danudey »

3pt14159 wrote: post #96
swagonomixxx wrote: post #85

I haven't used Ruby in ages but this seems like a really odd way to incorporate type hints in the language. I much prefer the Python 3+ approach of type annotations in source code. I can't imagine having to look at a separate file just to figure out what the type of something is. You may say "tooling will fix this" but it's just far less overhead for everyone at the end of the day to just make annotations in source.…

This is why I do not like mypy or types in Python other than dataclasses. If I'm going to type the damn thing I better be getting performance ala cython. Why on earth use a dynamic language like Ruby or Python and then try to bolt types on top. Ruby would do far better to fix the bloody `and` vs `&&` issue (it should just be `and` and it should work like `&&`) and strings should be immutable by default with a special…

> 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, list): var = list(var)

or

if not isinstance(var, list): raise ValueError("I know I didn't tell you I needed specifically a list, but I need specifically a list in this case")

Over and over and over again all over your module. Look, give me a list, I need a list. I need the APIs that list has, I need the interface it uses. I don't want a generator that I'm going to be iterating over forever, I don't want a string that's going to get split into individual characters.

Duck typing is all well and good, but just because strings, lists, sets, and os.walk are iterable doesn't mean I'm able or willing to handle those.

It can also help a lot in IDEs; for example, if I type-annotate a method to accept "name" as a Str, then my editor can assume that "name" is a string, even without any other evidence to that being the case. Likewise for things like warning about return types.

Lastly, it lets you do automated testing as well. Hey, you're passing a FooNode to this function, but that function accepts a list. I know this because NodeCollection.find() returns a FooNode. Makes it easy for the dev to look at the report and think "Oh, I meant to use NodeCollection.findall(), oops!"

I certainly don't want a statically typed language, but there are a lot of cases where my internal logic is fixed and I don't want my method to have to know how to deal with int, str, none, bytes, etc. Type annotations can solve this problem for me and for other people using my code.

Re: RBS, Ruby’s new type signature language

#117

Post by baweaver »

ativzzz wrote: post #83
joshuamorton wrote: post #47

Earlier quoted context omitted.

You can do both. Python allows for external .pyi files, for situations where you can't modify the underlying library (for example: it's written in C). There are tons of them: https://github.com/python/typeshed , but you can still add types to new code inline.

You can, but clearly the people designing this system have weighed the pros and cons and found that there would be more benefits to them to leave the source code unchanged.

Yeah, there was a ton of discussion on this in the Ruby bugtracker and at core meetings. Matz is very sensitive to breaking the language with Ruby 3 and the core team is doing their best to ensure an easy transition.

Re: RBS, Ruby’s new type signature language

#118

Post by mekster »

ativzzz wrote: post #29
azinman2 wrote: post #15

Earlier quoted context omitted.

But as I mentioned the downside of this is that any mistakes don't become evident until at runtime. While the python way has the same problem (they're not compiled languages after all), by inlining to the existing source there's less changes for divergence to happen.

Remember this is designed by companies that already have existing, large, ruby codebases. For them, it makes a lot of sense to be able to incrementally add typing without having to make changes to the underlying code itself.

So, why would a company with different use case than average ruby users implement stuff in the core to confuse many ruby users?

Re: RBS, Ruby’s new type signature language

#119

Post by rattray »

baweaver wrote: post #84
rattray wrote: post #71

Earlier quoted context omitted.

Yeah, I was wondering why this was being announced on Square's website. Seems it's because Square happens to employ Soutaro Matsumoto, who wrote the post and is also the creator of Steep[0] (an implementation of a typechecker for RBS files). It's not clear to me whether Soutaro is a member of the Ruby core team, so it feels a bit odd that the post is written like an announcement from the Ruby maintainers. [0] https:/…

Soutaro is indeed a code member of the Ruby team, he also happens to work at Square. Soutaro is also one of the main contributors to RBS and helped define that standard. He was going to keynote on this at RubyKaigi this year until it was cancelled, and had a talk at RubyConf as well on this.

Thanks for clarifying! It's great that Square is funding work like this.

Re: RBS, Ruby’s new type signature language

#120

Post by sparker72678 »

zeptonix wrote: post #95
jakearmitage wrote: post #81

Earlier quoted context omitted.

Which is great.

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 fits that mold.

So much of what I love about Ruby is what it doesn't make me do.

Post reply on HN