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

101–110 of 187 posts

Re: Stripe is building a Ruby typechecker

#101

Post by mattbessey »

hendzen wrote: post #57
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

I'm sure they will come up with some plausible reason like the project having incompatible goals, or embracing a different design architecture than the one they wanted. Truthfully, these 'prestige' projects are done for reasons other than actually improving the development standards. They probably didn't use RDL because it was more fun to write their own then figure out someone else's thing. For all we know they may…

It would seem your cynicism was unfounded https://news.ycombinator.com/item?id=17226332

Re: Stripe is building a Ruby typechecker

#102

Post by aczerepinski »

pmontra wrote: post #79
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.

I'm one of those people. I'm not sure I'd keep loving Ruby as much as I do now if the majority of Ruby developers end up using the type checker and I'll also have to. I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That was very welcome coming from C and Java in 2006. I prefer to lose time when I pass a type that I shouldn't have passed. It doesn't happen often (not every…

In my experience I lose less time specifying that an argument is a string in Go than I do adding a test to handle the possibility that nil gets passed in Ruby.

Re: Stripe is building a Ruby typechecker

#103

Post by nailer »

klmr wrote: post #98
nailer wrote: post #96

Earlier quoted context omitted.

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, t…

No problem! Thanks for clarifying.

Re: Stripe is building a Ruby typechecker

#104

Post by inopinatus »

vidarh wrote: post #95
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.

We only have the published examples to go on, but unfortunately they all seem to assume that type means class.

If that’s borne out I could never use this library. It’d be the antithesis of duck typing and object messaging.

Re: Stripe is building a Ruby typechecker

#105

Post by oelmekki »

vidarh wrote: post #97
oelmekki wrote: post #94

Earlier quoted context omitted.

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.

Oh, I see, given the interpreter is written in strongly typed language, allowing to go without static typing is a feature by itself, and allowing to test for methods presence allows to do duck typing, thus it allows to say that ruby implements duck typing.

It makes more sense than talking of duck typing explicit usage by end users, given it's quite rare we assert proper received parameters extensively.

EDIT : which makes me realize we have a machine language without typing (binary), on top of which we use a language implementing strong typing (C), used to build a language without strong typing (ruby), on top of which Stripe is building strong typing. Making a definitive decision is hard :)

Re: Stripe is building a Ruby typechecker

#106

Post by mbesto »

So you know when people ask "why does X startup have X,000 developers? what do they do all day for a single app[0]. Here is your answer:

"Technical details: - 9 month of work by 3 people; - real thing, runs over all code of #Stripe"

https://twitter.com/darkdimius/status/1002103748875902978

Now let's look at this from a financial perspective:

So let's say average $175k salary per employee + benefits and you're looking at easily north of $600k to do this.

I'm not saying it's "right" or "wrong", but thats just what companies at this scale do because they create development cultures and subsequent financial controls that allow for indirect production software development to happen.

[0]for the record, Stripe is much more complicated than just a "single app"

Re: Stripe is building a Ruby typechecker

#107

Post by mping »

matchbok wrote: post #27
mping wrote: post #15

Earlier quoted context omitted.

It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases t…

I've heard the "mentally model" argument a few times, and tbh I don't quite understand it. You have to model the object regardless, either with types or tons of extra checks to make sure that object has what you need. I've seen so much javascript code do exactly that because the methods had no idea what they were going to be given. The contract of static typing eases that load, I think.

Personally I feel that my mind is registering what each type does, kinda like building a mental dictionary. Dynlangs also have types but in terms of reading code it feels you can just skim through and skip the details. I guess there is a difference in the cognitive load of reading code and writing code.

Re: Stripe is building a Ruby typechecker

#108

Post by amelius »

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.

> boiling any number of oceans

How many lines of code are we talking about here?

Re: Stripe is building a Ruby typechecker

#109

Post by nextos »

ptarjan wrote: post #92
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. Bef…

You are embarking onto a very interesting, but tough project due to the extremely dynamic nature of Ruby!

Have you considered the property-based QuickCheck approach? Instead of building a type checker, you just annotate your code with properties (preconditions, postconditions and class invariants). You can generate tests to verify your code and also inject runtime checks to fail early in case of violations.

In my experience, this tends to work much better on dynamic languages and it also scales to larger codebases with heavy usage of dynamic idioms.

Re: Stripe is building a Ruby typechecker

#110

Post by golergka »

pmontra wrote: post #79
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.

I'm one of those people. I'm not sure I'd keep loving Ruby as much as I do now if the majority of Ruby developers end up using the type checker and I'll also have to. I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That was very welcome coming from C and Java in 2006. I prefer to lose time when I pass a type that I shouldn't have passed. It doesn't happen often (not every…

> I don't have to lose time writing types

In C#, I write type names when I declare a type, when I create instance of a type, when I declare method argument or return type (which you would probably do even in a dynamic language as a comment - you don't want people to have to go through your code to figure it out themselves, right?) and when I declare a collection of that type. Out of all of these, only the last one seems as "wasting time", because if I declare a collection and instantly use it on the next line, the reader can probably infer what type I meant to use - but in all other cases, not writing types would make the reader's job harder, not easier.

Don't the same principles apply when you're working in a dynamic language?

Post reply on HN