> I’m struck here by an analogy to the Linux kernel. Kernel developers often use “time to build the kernel” as a go-to benchmark when proposing kernel optimizations, because it’s a performance-intensive benchmark that every kernel developer, by construction, has readily at hand. Not coincidentally, the Linux kernel is drastically faster than any other production kernel I know of for certain operations that kernel builds exercise heavily, such as filesystem lookups. I think there’s a general lesson here that converting some desirable system property into a direct personal pain point for developers of the system creates very powerful feedback loops to ensure that property.
Nice observation. It's a generalization of how devs with slow computers write more efficient code.
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.
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.
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.
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.
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?
> 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.
> 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.
Nice observation. It's a generalization of how devs with slow computers write more efficient code.