Open-sourcing the Sorbet VS Code Extension

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

Our goal with new Sorbet versions is to break things where it makes sense (fix bugs, improve types for the standard library) which sometimes introduces new type errors in projects using Sorbet. But wherever possible, we try to build autocorrects that allow for fixing or silencing those breakages.

One little known feature here that works mostly well right now but could definitely be better is the `--suggest-unsafe` [1] flag, which will attempt to insert `T.unsafe(...)` in places in the program where there was a type error.

Then in places where we improved Sorbet so that it no longer thought something was untyped, and started reporting errors downstream, you could run `bundle exec srb tc --autocorrect --suggest-unsafe` once after upgrading, and commit or delete the autocorrects as desired.

It isn't a goal to have some sort of v1.0 milestone where new releases will not introduce type errors to a codebase that doesn't have any, which is I think what you're asking about.

[1]: https://github.com/sorbet/sorbet/blob/master/main/options/op...

(edited to clarify phrasing in response to child comment)

Thank you - Great looking release! Other Ruby extensions seemed like afterthoughts or incomplete efforts.

Does Stripe use Ruby enough internally to "bootstrap" this from the ground up?

Thanks for the info!

I don't use sorbet myself yet (although I am a ruby user), so this is not coming from any kind of educated basis, just an outside observer being curious, but I'm curious:

> We don't currently have a plan or a desire to get to a state where upgrading to a new Sorbet version will not introduce new errors on a codebase that previously type checked, which is what I think you might imply you want out of a v1.0 release.

That surprises me enough that I had to read it a couple times to make sure I was understanding how all the "not"s came out. I'd think that would be a thing you would straightforwardly want out of at type checker, the thing you said you don't have a plan or desire for. I'm interested in hearing more about why not, here or a link to somewhere else.

Stripe has a huge existing Ruby codebase that powers a lot of the dashboard and more. But there’s also a push towards Java for new services.

Notably, Stripe does not use Ruby on Rails: instead there’s a few homegrown frameworks used for routing, storing data in a database, etc.