Stripe is building a Ruby typechecker
medium.com
Stripe is building a Ruby typechecker
1–10 of 187 posts
Re: Stripe is building a Ruby typechecker
#2Not yet open-sourced, but this is definitely planned.
You can try it out there though: https://sorbet.run
By the way, a number of RubyKaigi 2018 talks were dealing with type checking (and the other were about improving performance & memory usage).
Re: Stripe is building a Ruby typechecker
#3Interesting! Anyone with insight into the ruby core team know if Ruby may add typing (optional or mandatory) in the future?
Re: Stripe is building a Ruby typechecker
#4Interesting choice, considering that Stripe is a massive Scala user.
Is it really cheaper to write type checking for one of the most dynamic languages ever, than port to their other language? Seems to be strong evidence against the "stack doesn't really matter" viewpoint.
Re: Stripe is building a Ruby typechecker
#5Interesting! Anyone with insight into the ruby core team know if Ruby may add typing (optional or mandatory) in the future?
Matz has talked about it as an opt-in. I think his opinion is to not force people to adopt it if they won't enjoy it or their productivity will be hampered by it.
Re: Stripe is building a Ruby typechecker
#6I 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.
Re: Stripe is building a Ruby typechecker
#7Not yet open-sourced, but this is definitely planned. You can try it out there though: https://sorbet.run By the way, a number of RubyKaigi 2018 talks were dealing with type checking (and the other were about improving performance & memory usage).
I had the "pleasure" of creating and integrating a parser for a custom DSL into ACE. I've created the parser in ~3 days; it took another 3 to make it work with ACE.
If it was up to me, I'd chose monaco editor (as the guys from mozilla did it with their webassembly editor)
Re: Stripe is building a Ruby typechecker
#8I 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.
Not sure I've ever heard anyone say static typing removes the need for testing.
Types are self-documenting. Onboarding new devs in a large static codebase will be 10x easier than a dynamic one.
Coding is actually faster in statically typed projects - autocomplete works every single time and you never have to dig into another source file to see what objects/methods you have.
And, most modern type systems (Typescript, Swift, etc) don't have much overhead at all with their impressive type inference.
Re: Stripe is building a Ruby typechecker
#9ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]?
It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are.
The best argument for this (instead of Crystal) is keeping access to ruby gems.
Re: Stripe is building a Ruby typechecker
#10ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/
My 100k LOC code base is already written in ruby though. I have to rewrite everything?