Hacker News new | ask | show | jobs
by bradleybuda 2113 days ago
Our team has been using Sorbet at getcensus.com for almost a year now, and I'm generally very happy with it though it's not perfect.

Like most non-trivial Rails apps, our test suite takes a while to run, so I like having Sorbet to catch "dumb" issues without having to run the full suite. Running `srb tc` to check types is incredibly fast and seems to be scaling well as our codebase grows. It catches the obvious stuff, but has also found some subtle bugs in flow checking and is great for refactoring support. The false positive rate is extremely low - if Sorbet flags a regression in your type checking, it's very likely to be a real bug.

The Slack community is helpful and responsive - if you're thinking of using sorbet, I'd strongly suggest joining.

The downsides are:

- Unclear workflows - it's hard to know when you need to "rescan" for new type definitions in gems, the stdlib, and in generated code in your own app

- Poor Rails integration - the sorbet-rails package is helpful and being actively developed, but it's clear that the maintainers don't use Rails and aren't going out of their way to support it.

- Upgrades are rough - the sorbet tools that scan your gems and code to find "hidden definitions" are seemingly unstable from release to release. There's a good chance that upgrading to a new version of sorbet will break your type checking for mysterious and hard-to-debug reasons. Lots of this is probably related to Rails as well.

- IDE integration isn't quite ready for prime-time yet. I've gotten it working in Emacs with lots of experimentation and poking around, and I think some folks have it working in VSCode too, but it's not officially "released" or supported and it crashes somewhat often. It's still stable enough to be useful and I'm glad I have it.

It's great and seems to be getting better, and it has absolutely made me more productive, but know that you're still adopting an alpha- or beta-quality tool and it's unlikely to "just work".

1 comments

sob on sorbet-rails

j/k. sorbet-rails maintainer here. I agree with the assessment that sorbet doesn't go out of the way to support some Rails feature, eg method overloading or scoping block accurately. Sorbet tool is opinionated about some of the design choices that makes it hard to support Rails' extensive use of meta-programming. That said, Sorbet is still useful in checking the custom code we write on top of Rails and their interactions. It may be hard to type the model files themselves, but we can type-check the code making use of the models! Recently, I started a new project on Rails and it's quite fun building it with type from scratch :D

I find Sorbet a very helpful tool for development. I hope people will give it a try and contribute to tools around it (sorbet-rails included) so that we have great tools to use!

For those who are interested in the topic, I outlined some of the technical challenges with using Sorbet on rails here https://medium.com/czi-technology/static-type-checking-in-ra...

I did not mean to put down sorbet-rails - it has been really useful to us and we appreciate all the work you and your team have put in to it!

But I do have the sense that building Rails apps using sorbet won't feel "first class" until we have some sorbet maintainers that use Rails or the Rails team starts adopting sorbet (or both!)

Yeah, I totally agree with this. In some way, it's the difference in philosophical approach of the two system that it'll be hard to reconcile. Eg: Rails favors convenience (method that just works under various condition), whereas Sorbet favors explicitness (no method overloading, typed struct class instead of hash)