Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe is building a Ruby typechecker

medium.com

Post reply on HN
Print view View original

91–100 of 187 posts

Re: Stripe is building a Ruby typechecker

#91

Post by vidarh »

oelmekki wrote: post #88
fouc wrote: post #84

Earlier quoted context omitted.

Ruby has the advantage of 'duck typing', due to its strong OOP foundations. Not quite sure what Python has that reduces the demand for static type declaration. I think part of the popularity of TypeScript could be down to a large proportion of javascript coders that have a background/preference for static typing. It could also be that certain classes of bugs are more prone to happen in JavaScript or it's harder to de…

Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its interfaces (a type implements an interface if it implements its methods, so we can use interface as function parameter type). I don't get why we talk of duck typing about ruby : if I pass as parameter an object that does not quack like a duck, nothing will prev…

The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests.

Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class.

E.g. if you have:

    def foo source
      dosomething(source.shift)
    end
Then absent additional restrictions inferred from requirements of dosomething(), the class of "source" is irrelevant. The relevant type information is whether or not "source" responds to "shift".

A proper Ruby-ish type checker will need to be able to handle that, or it'll push people to write non-idiomatic Ruby.

Re: Stripe is building a Ruby typechecker

#92

Post by ptarjan »

sankha93 wrote: post #53

Any reason why existing typecheckers for Ruby didn't make the cut? There are projects like RDL [1] which provide similar functionality. I know for certain that people from Stripe were taking a look at it last year from the issues they had raised. Disclosure: I am a grad student, recently started working on RDL. [1]: https://github.com/plum-umd/rdl

Hi and thank you for working on RDL! We do love the project and spoke with Jeff Foster a few times last year.

We did use your standard library annotations for Sorbet and have many fixes to them sitting in your pull request queue: https://github.com/plum-umd/rdl/pull/68 https://github.com/plum-umd/rdl/pull/72 https://github.com/plum-umd/rdl/pull/57 . We stopped submitting more since these weren't being upstreamed.

Before we started our project, I evaluated rolling out RDL instead of building our own typechecker. Trust me, I would MUCH rather use an existing project than have to build our own, but sadly it just didn't scale to our millions of lines of code.

I'm more than happy to chat about the details of why we didn't use RDL if you'd like to email me at sorbet@stripe.com. Thanks again for your great project, we're standing on the shoulders of giants.

Re: Stripe is building a Ruby typechecker

#93

Post by _pmf_ »

Kalium wrote: post #42

"Why don't they just use (insert static-typed system here) instead?" someone will inevitably ask. "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.

> "Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem."

Sometimes, if a baby is really, really ugly, it's OK to throw it out with the bathwater.

Re: Stripe is building a Ruby typechecker

#94

Post by oelmekki »

vidarh wrote: post #91
oelmekki wrote: post #88

Earlier quoted context omitted.

Ruby has been my first professional language and I've sticked with it for a decade, but I never really understood duck typing before switching to Go, with its interfaces (a type implements an interface if it implements its methods, so we can use interface as function parameter type). I don't get why we talk of duck typing about ruby : if I pass as parameter an object that does not quack like a duck, nothing will prev…

The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirem…

I've digged a bit on the subject (better late than never), it seems that duck typing is seen in ruby as a guideline, rather than a language feature. Basically, it's about recommending to use `#respond_to?` rather than `#is_a?`, `#kind_of?` or `Class#===` in end user code.

Re: Stripe is building a Ruby typechecker

#95

Post by vidarh »

ptarjan wrote: post #90

Thank you so much for all the interest! We're flattered and excited to see all the discussion about the project. Try it out: https://sorbet.run If you would like to get in touch with us about anything, please email us at sorbet@stripe.com. In the presentation at RubyKaigi (which will be available online soon) we explicitly mentioned we'd like to chat with folks trying to scale Ruby into the millions of lines of code,…

One thing that springs to mind: Does it handle duck-typing? In other words, can I specify "any object that responds to methods x and y" as the expected type of a variable?

Because if treats classes as equivalent to types, then to me it encourages non-idiomatic Ruby.

Re: Stripe is building a Ruby typechecker

#96

Post by nailer »

klmr wrote: post #86
nailer wrote: post #85

Earlier quoted context omitted.

I'm not a typing person, similar to pmontra. Any programming language where print("Hello world") is longer than print("Hello world") bothers me. And most of my JavaScript is untyped, because (and apparently this is common, someone did some stats on it a while ago) typing errors aren't a great source of errors. However I love optional typing . Being able to build a thing quickly, and then add those guarantees if/when…

> typing errors aren't a great source of errors. That’s not true. On the contrary, typing accounts for a substantial fraction of all errors (and refactoring could transform even more logic errors into catchable type errors). The best research (best methodology, sample size, by far) on the subject [1] puts the lower bound for the fraction of type errors in JavaScript at 15%. [1] https://paperpile.com/app/p/3070170e-93…

Not doing a URL hunt as I'm at work, but as mentioned in the comment you're replying to (literally after you chopped it off), there was a large study showing the opposite on HN a while back.

Re: Stripe is building a Ruby typechecker

#97

Post by vidarh »

oelmekki wrote: post #94
vidarh wrote: post #91

Earlier quoted context omitted.

The obvious part is that Ruby does not have a distinction between "compile time" and "runtime". As such, if you want to catch those cases, you need tests. Duck-typing can be boiled down to: The type of a parameter to a function is defined by the methods that will be called on it, not by its class. E.g. if you have: def foo source dosomething(source.shift) end Then absent additional restrictions inferred from requirem…

I've digged a bit on the subject (better late than never), it seems that duck typing is seen in ruby as a guideline, rather than a language feature. Basically, it's about recommending to use `#respond_to?` rather than `#is_a?`, `#kind_of?` or `Class#===` in end user code.

It's a language feature in as much as the absence of static typing and the ability to check for methods is what makes it possible.

But yes, it it a guideline, and Ruby code that violates it will generally be seen as not being idiomatic Ruby.

Re: Stripe is building a Ruby typechecker

#98

Post by klmr »

nailer wrote: post #96
klmr wrote: post #86

Earlier quoted context omitted.

> typing errors aren't a great source of errors. That’s not true. On the contrary, typing accounts for a substantial fraction of all errors (and refactoring could transform even more logic errors into catchable type errors). The best research (best methodology, sample size, by far) on the subject [1] puts the lower bound for the fraction of type errors in JavaScript at 15%. [1] https://paperpile.com/app/p/3070170e-93…

Not doing a URL hunt as I'm at work, but as mentioned in the comment you're replying to (literally after you chopped it off), there was a large study showing the opposite on HN a while back.

> there was a large study showing the opposite on HN a while back.

Yes, sorry: I didn’t mean to ignore that part of your answer but the research I’ve linked to essentially supersedes everything else in that area. Prior studies were riddled with inadequacies in controlling for confounders and outright methodological errors. I’m assuming you’re referring to [1] and while that was an impressive study in its own right, their classification of bug sources is indirect and, ultimately, simply didn’t allow any assertions regarding the prevalence of type errors.

[1] https://paperpile.com/app/p/54ee3fdd-a6ef-0767-add5-55b60419...

Re: Stripe is building a Ruby typechecker

#99

Post by vemv »

Typical Rails codebases already enjoy a reasonable layer of 'typing' via ActiveRecord coercions, validations, and possibly some system that declares/documents the types/structure of your REST API.

Also, I advocate keyword arguments (especially 'required' ones), which tend to kill 80% of the use case of typing for dynlangs ("what's the type of argument x?")

A meaningful test suite would hammer the last nail in the coffin.

Re: Stripe is building a Ruby typechecker

#100

Post by faitswulff »

taf2 wrote: post #31

This looks really nice... i wish it was just part of the language to be able to write ruby with type information e.g. instead of having a separate more verbose sig method that's called before each method signature... ``` class Foo extend T::Helpers sig( # Both positional and named parameters are referred to by name. # You must declare all parameters (and the return value below). foobar: Integer, widget: String ) .ret…

I don't know, as a long-time Rubyist, I actually prefer Sorbet's fluent interface with `sig(...).return(...)` to these (albeit more typical) type annotations. Reminds me of RSpec.
Post reply on HN