I remember having mixed feelings about Sorbet when I first joined Stripe in late 2018, but by the time I left, I found it indispensable. Especially after the VS Code extension was released internally... holy crap, that made such a huge difference (vs having CI fail 20 mins after pushing up a PR because you forgot to run the typechecker script ahead of time, ugh).<p>This article also made me laugh, because it reminded me of one of my small pet peeves about the Ruby codebase at Stripe: the fact that you would often find `merchant`, `account`, `invoice`, etc used as method parameters that represented the _ID_ of the resource rather than the resource itself. So Sorbet definitely helped with that, but it also could've been nice to just write `invoice_id` instead... :P<p>Makes me nostalgic though, good times!
We've been starting to use Sorbet at Figma and honestly it's been pretty cool! Sorbet is definitely not as good at TypeScript (yet?). It's more verbose, doesn't support things like recursive types and records (shapes are experimental), and it doesn't inspire the same confidence TS does but it's definitely worth it to add it to your codebase if it's big enough!<p>Also, it's fast! I'm in total agreement with the point made in the article. That makes a huge difference in developer UX.
Sorbet and/or RBS seems like they may be the future given how popular typescript is with JS programmers these days. There are some other projects that assist programmers without relying on formal type definitions in the source or shadow typing files:<p>Solargraph combines inference and insight from YARD docs (standard for many gems, plus Castwide has written more YARD for the standard library) to make some pretty good guesses. Crucially it has plugins that add the insights from popular gems with static analysis (e.g. reek, rubocop). I maintain solargraph-rails, which parses your Ruby to make guesses about (surprise) Rails.<p>The typeprof gem can help IDE plugins make typing guesses based on your tests. This project is interesting to me because it's going into Ruby 3.1 so I think it reflects awareness from the core ruby team that many programmers are not ready to add types to their code.<p>solargraph: <a href="https://github.com/castwide/solargraph" rel="nofollow">https://github.com/castwide/solargraph</a>
solargraph-rails: <a href="https://github.com/iftheshoefritz/solargraph-rails" rel="nofollow">https://github.com/iftheshoefritz/solargraph-rails</a>
typeprof: <a href="https://www.youtube.com/watch?v=UTMj51j9yEg" rel="nofollow">https://www.youtube.com/watch?v=UTMj51j9yEg</a>
Sorbet is very useful, but the ergonomics suck. It’s fucking difficult to write rspec tests. The performance overhead of writing sorbet on rails in a big codebase is so much that we have turned it off. The pre-interpreter type checking is somewhat useful.<p>The alpha releases are also a big concern. We are stuck on a 300 commit (release) old build and can never upgrade safely.<p>We have also never been able to get the VSCode extensions to run.<p>Thanks for Sorbet, but I’d suggest people outside Stripe to look elsewhere.
My problem with Sorbet is how ugly it looks. It's probably not possible to do with Ruby (now) but Crystal does it better[1] while (mostly) retaining the syntax of Ruby. I suppose it's trying for Elixir's @spec, which I like less than Crystal's sigs but still prefer over this.<p>Still, if it helps it helps.<p>[1] <a href="https://crystal-lang.org/reference/1.3/tutorials/basics/60_methods.html" rel="nofollow">https://crystal-lang.org/reference/1.3/tutorials/basics/60_m...</a><p>Edit: Perhaps I spoke too soon <a href="https://blog.appsignal.com/2021/01/27/rbs-the-new-ruby-3-typing-language-in-action.html" rel="nofollow">https://blog.appsignal.com/2021/01/27/rbs-the-new-ruby-3-typ...</a>
To be honest I struggle with the frustration of programmers of dynamic languages building their own (mostly half-assed) type checkers, after years and years of dealing with their bogus arguments about why dynamic languages are superior and all you need is unit tests (the same cohort is also now on a misguided crusade against unit tests but that's a whole other story).<p>At least the JS crowd had the decency to buy into a whole new (far better) language instead of a bolt-on solution.
I tried using sorbet on our project, but the type system it supports is way too poor.
The most glaring problem is the lack of support for duck typing, only nominal typing is supported, no structural typing.<p>For key parts of the code, there was no type safety where we expected it.<p>In the end, it felt far from being like Typescript, we opted for removing it, instead we added some runtime type checking and we document with YARD. Far from ideal, but that's the tooling available.<p>The gem integration is terrible currently: we wrote the gem, fully typed with sorbet, but for some reason the type checking was completely ignored in the main project where we referred it
Sorbet is <i>sooo</i> close to being idiomatic in Ruby. With some support for duck typing and roughing out edges around memoization / ivars, I could see it being adopted into Ruby proper.
I spent about two weeks trying to use Sorbet while working on a rails codebase. For context, I'm a huge typing fan, and use it even when writing 10 line scripts in Python. Here were my feelings:<p>The TLDR for me is: I’d still be willing to keep using sorbet, if issue number 4 below (that the LSP isn’t very responsive) would be fixed. Otherwise, it adds more work than it removes from my workflow, so I've stopped trying it out.<p>Start with the negatives:
1. It’s a lot of grunt work to set it up properly in an application like ours with many dependencies. Specifically, sorbet and/or related tooling tries to generate RBI (equivalent of typescript’s index.d.ts) files by actually importing and running your code, and doing introspection on the types of the arguments of functions. I managed to work around this problem, but it’s a reflection of how young Ruby typing is as a whole that this step was a time-sink for me.<p>2. There’s no mechanism to do the equivalent of yarn add -D @types/react-table (which would install typings for the react-table package). You basically have to copy paste from this github repo[0] manually.<p>3. Some really popular gems still don’t have types. For example, IIRC, devise’s typings are either non-existent or are uselessly incomplete.<p>4. The sorbet LSP isn’t very responsive, at least in neovim. I asked @jez about this just now, so hopefully I'll get a response.<p>5. Super verbose syntax.<p>Positives:
1. Thanks to this repo[1], there’s actually a way to easily generate typings that would cover a lot of the dynamism of rails, it works quite well.<p>2. It’s legit helped me catch errors with my code.<p>[0] <a href="https://github.com/sorbet/sorbet-typed" rel="nofollow">https://github.com/sorbet/sorbet-typed</a><p>[1] <a href="https://github.com/chanzuckerberg/sorbet-rails" rel="nofollow">https://github.com/chanzuckerberg/sorbet-rails</a>