Live data from Hacker News

Open-sourcing the Sorbet VS Code Extension

sorbet.org

21–30 of 88 posts

Re: Open-sourcing the Sorbet VS Code Extension

#22

Earlier quoted context omitted.

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.

Why the push towards Java for new services?

A robust performant multithreaded runtime with a big set of enterprise libraries for the big boys.

Re: Open-sourcing the Sorbet VS Code Extension

#23
post #17
post #15

Earlier quoted context omitted.

I don't see why it wouldn't be supported! If the APIs are the same as VS Code's APIs, you should be able to build the VS Code extension from source and load it into VSCodium at your convenience.

Yeah, VSCodium is just a build of the open-source VSCode base, it just can't connect to Microsoft's extension store because that's reserved for Microsoft's proprietary build. It should have the same APIs. I just wondered if the maintainers would officially support this use case. I'm not a VSCode user, but I do not trust Microsoft to dominate the entire dev tool ecosystem, and a stronger alternative base built around…

You can download the extension off of the official VSCode extension store in a web browser and install it manually in VSCodium.

Re: Open-sourcing the Sorbet VS Code Extension

#24
Thanks for this great project. It's amazing that: - It works both for static analysis and runtime checks (unlike Typescript); - Static analysis runs super fast even in a large codebase (unlike Erlang's /Elixir's dialyzer).

It's a shame that it didn't become the official Ruby type checker.

Re: Open-sourcing the Sorbet VS Code Extension

#25

Thanks for this great project. It's amazing that: - It works both for static analysis and runtime checks (unlike Typescript); - Static analysis runs super fast even in a large codebase (unlike Erlang's /Elixir's dialyzer). It's a shame that it didn't become the official Ruby type checker.

Yeah I'm sad about that too. I really dislike the official implementation because I can't easily see the function signature requirements.

Maybe w/ a VSCode extension but that means i can't read the signature a browser.

Re: Open-sourcing the Sorbet VS Code Extension

#27
post #9

Earlier quoted context omitted.

If Sorbet knows the type of the receiver of the method call, it will suggest completion results, regardless of whether any of the suggestions themselves have sigs, or whether you're inside a method with a signature. But without any sigs, there aren't going to necessarily be as many opportunities for Sorbet to know the type of the receiver as there would be with sigs. Here's an example https://sorbet.run/#%23%20typed%…

Even if I dont have signatures in my code, can I use it to get stdlib/gems signatures?

stdlib rbis are shipped with Sorbet. A limited selection of gem RBIs are available at https://github.com/sorbet/sorbet-typed.

Re: Open-sourcing the Sorbet VS Code Extension

#29
post #28

It's funny how we hear so much about Ruby's decline yet 3 of the highest-valued startups - Stripe, Shopify and AirBnB - are up there making fortunes with it whilst contributing to Ruby's vibrant ecosystem.

Oh wow. they still use Ruby at Airbnb? For some Reason I thought they'd moved to Go or the JVM.

Re: Open-sourcing the Sorbet VS Code Extension

#30

Earlier quoted context omitted.

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.

Why the push towards Java for new services?

Speculating but aside from the enterprise ecosystem advantages it's hard as hell to hire senior ruby devs.
Post reply on HN