Why the Sorbet type checker is fast(blog.nelhage.com)
blog.nelhage.com
Why the Sorbet type checker is fast
https://blog.nelhage.com/post/why-sorbet-is-fast/
16 comments
Somewhat related, to get optimizations into Wirth's Oberon compiler required the optimizations to 'pay for themselves':
Compiling the compiler with a version the optimization added had to be at least as fast as without, so the speed improvement it provided had to outweigh both the extra code it added to the source, and the runtime complexity.
It didn't serve to make it optimize well, but it served its purpose in keeping the compiler lean and simple to understand, and ensuring fast compilation.
Compiling the compiler with a version the optimization added had to be at least as fast as without, so the speed improvement it provided had to outweigh both the extra code it added to the source, and the runtime complexity.
It didn't serve to make it optimize well, but it served its purpose in keeping the compiler lean and simple to understand, and ensuring fast compilation.
As an aside, it's amazing how much work Stripe has put into Sorbet. More than half of the ~100 contributers work at Stripe: https://github.com/sorbet/sorbet/graphs/contributors
It's actually the opposite: most contributors to Sorbet are outside of Stripe:
https://sorbet.run/talks/RubyConf2019/#/22
(I work on the Sorbet team)
https://sorbet.run/talks/RubyConf2019/#/22
(I work on the Sorbet team)
Here's "git shortlog -sne", with Stripe employees (current and former) and email addresses removed. I've annotated with current company, if easily-discoverable: https://gist.github.com/muglug/a70b7316f92d05f9febbf56684a8e...
That list is a minority of all 166 in the original (and there may still be some Stripe accounts there).
Additionally all of the top 10 are current or former Stripe employees, and at least 96% of all commits come from current or former Stripe employees.
BUT there's also nothing wrong with this – in a similar project I created (https://github.com/vimeo/psalm), 90% of the commits come from employees at Vimeo. I was just pointing out it's good.
That list is a minority of all 166 in the original (and there may still be some Stripe accounts there).
Additionally all of the top 10 are current or former Stripe employees, and at least 96% of all commits come from current or former Stripe employees.
BUT there's also nothing wrong with this – in a similar project I created (https://github.com/vimeo/psalm), 90% of the commits come from employees at Vimeo. I was just pointing out it's good.
But I assume his original point still stands, Stripe did the absolute vast majority of work on Sorbet?
>As an aside, it's amazing how much work Stripe has put into Sorbet.
In case it wasn't obvious to people reading about Sorbet for the first time.
>As an aside, it's amazing how much work Stripe has put into Sorbet.
In case it wasn't obvious to people reading about Sorbet for the first time.
Yep. It didn’t make the slide deck but about 75% of the commits are from the core Sorbet team, which is all at Stripe.
But I think it’s important to emphasize both sides: Sorbet is not just some tool that only people at Stripe use and contribute to. It’s growing in both popularity and contributions in many places outside of Stripe.
But I think it’s important to emphasize both sides: Sorbet is not just some tool that only people at Stripe use and contribute to. It’s growing in both popularity and contributions in many places outside of Stripe.
That's not that shocking considering Stripe started Sorbet, right?
Tangentially related but what is the experience of introducing Sorbet into an existing Ruby codebase? How does it compare to rewriting Javascript code to Typescript? Does it provide benefits quickly or only after the whole thing is typed? Are there many gems already typed?
I work for one of the companies that partnered with Stripe and have been using Sorbet for ~1 year in prod now (before it was made public).
1. You can migrate class by class or even method by method. 2. You add type support to a method by prefixing it with a special lambda (Sig) that is read at class evaluation. 3. It provides its benefits right away. But really, most value comes from network effects. You won't get type warnings if the method you're calling isnt typed, because the return type cannot then be inferred. 4. No gems are typed right now. We type out type definitions for external dependencies in *.rbi files.
It's funny that you mention typescript because in that sense the two are quite similar. Types are defined either inline or in separate files .rbi/types.d
Opinions in the company are split probably roughly ~60/40 if Sorbet is worth the effort or not with support having a smallish majority.
1. You can migrate class by class or even method by method. 2. You add type support to a method by prefixing it with a special lambda (Sig) that is read at class evaluation. 3. It provides its benefits right away. But really, most value comes from network effects. You won't get type warnings if the method you're calling isnt typed, because the return type cannot then be inferred. 4. No gems are typed right now. We type out type definitions for external dependencies in *.rbi files.
It's funny that you mention typescript because in that sense the two are quite similar. Types are defined either inline or in separate files .rbi/types.d
Opinions in the company are split probably roughly ~60/40 if Sorbet is worth the effort or not with support having a smallish majority.
I also had a similar question as the GP, but more specifically, is it useful for a Rails app? I'm trying to think how much code we actually have that performs "deeper" business-logic, and then it tends to be also used in very specific paths... There isn't a huge amount of that. So is Sorbet helpful for views/controllers/models/presenters as well?
What were the opposing side's concern or argument against it?
Using Rails?
Using Rails?
> 1. You can migrate class by class or even method by method.
This is only if you can get it to run on your project. Far as I know, you can't segment it to just a few folders, can you? Our project has tens of thousands of files and even running it all night, it eventually hard crashes.
This is only if you can get it to run on your project. Far as I know, you can't segment it to just a few folders, can you? Our project has tens of thousands of files and even running it all night, it eventually hard crashes.
Does disabling it (using # typed: ignore) for all files but in that folder work? https://sorbet.org/docs/static
> These tests include fuzz testing, as well as running a “shadow build” in Stripe’s CI that runs over every pull request to the monorepo, but reports failures only to the Sorbet developers, instead of to the PR author.
What a great idea!
What a great idea!
A nice demo of Sorbet in action - https://youtu.be/jielBIZ40mw?t=837
Nice observation. It's a generalization of how devs with slow computers write more efficient code.