Hacker News Reader

Comment by jez | Hacker News Reader

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

Two questions (sorry if that's too much):

1. Sorbet isn't really great to use with Rails. I tried it out about a year ago - a few things might've changed but from scanning the relevant gems I think this broadly still applies. I used sorbet-rails but there were still a bunch of rough edges, eg. with using a class method on a model as a scope. The general theme was that Rails was doing quite a few things that make it super hard to type. ex - look at what it takes to do a type-safe pluck with sorbet-rails, and I don't think doing a typesafe select with association columns is even supported. Is there any acknowledgement of this from the Sorbet team itself, and will there be more to make the Sorbet with Rails experience better?

2. I'm really excited for the future of the Sorbet compiler. Like above, is there any work on making the AOT compiler work better with Rails?

Not OP, but hopefully this helps with your first point: we're happily using Sorbet with Rails (leveraging sorbet-rails). It's by no means perfect, but a gradual typing experience in Ruby never will be, unless you restrict the way you use the language. The benefits of having at least some level of type-checking outweigh the cons, IMHO. Sorbet picks up many of the little typos that only become apparent when you try out the code / run a test. I've been using an unofficial VS Code extension for ages, and I really like the increase in iteration speed.

Regarding Sorbet and Rails, I recommend Tapioca [1].

The Rails app that I worked on had a few edge cases Tapioca didn't cover so I wrote a simple script to load the Rails app and generate RBI files (e.g. generate RBI definitions for fixture methods in ApplicationTestCase). The Tapioca codebase helped provide a path for that [2]. Tapioca also continues to add to their DSL compilers. The work to integrate Sorbet paid off very quickly.

Also, T::Enum and T::Struct are handy in any Ruby codebase.

[1] https://github.com/Shopify/tapioca [2] https://github.com/Shopify/tapioca/tree/main/lib/tapioca/com...

1. I don’t know much about using Sorbet with Rails, but I do know that almost every major user of Sorbet that isn’t Stripe is using Sorbet with Rails! You might want to reach out in the #rails channel on our Sorbet Slack[1] for more?

2. Our focus for the Sorbet Compiler has always been more inward focused than Sorbet, so we focused pretty much exclusively on features that make the compiled code run fast on Stripe’s codebase. But you might be curious to read more about YJIT, the JIT compiler that was recently merged into Ruby 3.1—it’s being primarily developed by a team at Shopify where Rails performance is the highest priority.

[1] https://sorbet.org/slack

Is there official support for Sublime Text 3? I tried making it work a while ago and it wasn't easy to get it running.

We don't have anything custom on our end, but Sorbet implements the Language Server Protocol which it looks like Sublime Text 3 supports:

https://lsp.sublimetext.io/language_servers/#sorbet

These docs seem to even already have a snippet you should be able to add to your config to integrate Sorbet with Sublime Text 3.

I know Shopify are using it [1], Do you know if Github or Basecamp are using it too?

[1] https://twitter.com/rafaelfranca/status/1479259699694477312

I haven't heard anything from GitHub one way or another about whether they use Sorbet.

I'd be extremely surprised if Basecamp was using it, as DHH has always been particularly opposed to types, but again, I haven't heard anything one way or another from them.

Thanks for all the work! I've been wondering, are we to expect v1.0 at some point or we'll rely on daily/hourly new versions/updates?

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)

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.

Here's an example PR from a few days ago where someone contributed an improvement to the type definitions Sorbet maintains for the standard library:

https://github.com/sorbet/sorbet/pull/5024

By adding those type definitions, any downstream projects using Sorbet that happened to use those definitions incorrectly will start to see new type errors.

Here's another example:

https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3A...

This example shows a bug in how Sorbet handles shape types, that we definitely want to fix in the future but haven't had the time to yet. When we fix that, any project using shape types incorrectly will suddenly have new type errors.

The "not" is that they want freedom to make the type checker more strict, ie expand it to detect type errors it failed to detect previously

Any chance of this becoming supported in VSCodium?

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 VSCodium would be a good thing.

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

This might be a dumb question but is there a chosen license for the this source ?

We open sourced it by merging it into the Sorbet repo, under which all code is Apache 2.0 licensed:

https://github.com/sorbet/sorbet/blob/master/LICENSE

I'm just wondering why this wasn't open-source to start with

when shall we expect RBS support?

Reply on news.ycombinator.com