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

81–90 of 187 posts

Re: Stripe is building a Ruby typechecker

#81

Post by klmr »

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 like Ruby in part because it's strongly typed but I don't have to lose time writing types.

That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice everywhere (in languages that don’t support it in the language, it’s done in documentation).

> To understand if this project could have a future outside Stripe, how popular is Python 3.6's optional static type declaration?

Or rather: How popular are TypeScript or Flow? Very.

Re: Stripe is building a Ruby typechecker

#82

Post by klmr »

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

Sorbet appears to be a language extension rather than a library, similar to TypeScript or Flow in the JavaScript ecosystem. I’m guessing that one of their goals was ease of use for type annotations. I’ve had a quick look at RDL and while I quite like its syntax it is somewhat more cumbersome than having type annotations “inline”, as it were. Furthermore, the annotations in RDL are themselves stringly typed, which comes with its own issues.

Re: Stripe is building a Ruby typechecker

#83

Post by ksec »

exolymph wrote: post #69
hendzen wrote: post #57

Earlier quoted context omitted.

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…

Sure, that's possible, but we don't really have enough information to say either way.

I think they mentioned they will present more information in an up coming conference. And it makes this TypeChecker possibly the most battle tested solution out of all the competing ones.

Re: Stripe is building a Ruby typechecker

#84

Post by fouc »

klmr wrote: post #81
pmontra wrote: post #79

Earlier quoted context omitted.

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 like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice e…

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 debug when bugs do happen?

Re: Stripe is building a Ruby typechecker

#85

Post by nailer »

klmr wrote: post #81
pmontra wrote: post #79

Earlier quoted context omitted.

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 like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice e…

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 you feel they're needed is great. My current codebase is about 80 modules. Nearly all are untyped JS. The database code is TypeScript because that's where I feel type handling would add the greatest benefit - not that I have had typing errors, just that I like the additional peace of mind.

Re: Stripe is building a Ruby typechecker

#86

Post by klmr »

nailer wrote: post #85
klmr wrote: post #81

Earlier quoted context omitted.

> I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice e…

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-933e-0956-82ec-879fb924...

Re: Stripe is building a Ruby typechecker

#87

Post by pg_bot »

Tehnix wrote: post #24
pg_bot wrote: post #6

I don't understand the appeal of static typing. It always feels like I'm adding overhead without receiving any benefits. I've worked in some fairly large dynamically typed codebases and have never run into issues with type errors. Static typing does not alleviate the need to test your code, which is a more effective way of reducing bugs in your system than annotating your methods/functions.

What languages have you worked with before, with static types? If it's something like Java, C, C++, etc, then I can see your point, but if you pick any of the languages with type inference (like Elm, Haskell, PureScript, OCaml, F#, etc), then you rarely actually have to write types. Working with the type system is a different way of working. It's more beneficial to see the compiler as a helping friend, instead of an…

The languages that I've used with static typing are Java and Objective-C so perhaps those languages have negatively impacted my perception of type systems. I can do more research on other languages to see what they have to offer.

I used to run into type errors when I first started programming but I've learned how to eliminate them by changing my programming style. I add a lot of constraints to how I program, and follow a system of naming conventions that make it obvious what type something is.

I take a lot of pride in my work and try my best to build maintainable systems that can be extended easily or run forever without changes. I typically write around 250K-350K lines of code per year in mission critical and highly regulated industries. If you want to learn how to write systems that have zero defects research companies that are known for quality design and apply their principles to your own work. I would suggest Netflix, and Toyota as the two companies that I would emulate.

Re: Stripe is building a Ruby typechecker

#88

Post by oelmekki »

fouc wrote: post #84
klmr wrote: post #81

Earlier quoted context omitted.

> I like Ruby in part because it's strongly typed but I don't have to lose time writing types. That’s why type inference exists. Static typing doesn’t imply annotating everything manually with types. Granted, most static type systems require (or at least encourage) this but it’s not necessary everywhere (or indeed for most usage). Annotating public interfaces with types is, I’d argue strongly, already best practice e…

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 prevent me to do it and it will generate an exception when quacking. Did I miss something obvious?

Re: Stripe is building a Ruby typechecker

#89

Post by quelltext »

griffinheart wrote: post #64
sandstrom wrote: post #3

Interesting! Anyone with insight into the ruby core team know if Ruby may add typing (optional or mandatory) in the future?

Was at the Kaigi and on the opening keynote Matz talked a bit about it. He doesn't really support adding it since he feels like in 20/30+ years, advances in technology will make writing types "obsolete".

It's a weird argument. If it's not necessary in 30 years (I doubt it because some of the type inference issues are simply undecidable, and that in much simpler languages already), then the language can just opt to ignore type annotations or merely check their consistency. Having them is great either way for the benefit of documentation.

My take is he doesn't really like (or "get") types and feels protective of his language, which is fair. I think Python made an interesting choice here, i.e. provide syntax for types without semantics. The drawback there is potential fragmentation on type system semantics.

Re: Stripe is building a Ruby typechecker

#90

Post by ptarjan »

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, or folks also working on similar typechecking projects. Of course feel free to email even if you aren't in those groups, but I wanted to get your attention if you were.

Post reply on HN