Static Typing for Ruby: Adopting Sorbet at Scale

Post by mercer » Sat, Nov 21, 2020, 9:15 PM UTC

ibraheemdev wrote: post #43

aerovistae wrote: post #24

Earlier quoted context omitted.

God do I love Ruby. It's just such a beautiful language. Feels more expressive and imaginative than any other language I've touched by a mile. But while I personally enjoy it more than Python, Python will always be the one I would recommend to anyone for work or learning-- it's so much more straightforward and predictable. The "one right way to do things" mentality that pervades python makes things so consistent and…

In the words of David Heinemeier Hansson: > In fact, Ruby, to me, so much of the enjoyment in Ruby is these incredible subtleties, of how many different ways you can structure a conditional. Like, Ruby has, I don't know even the count, there's gotta be 60 different ways you can say `if something`, right? And it is in those 60 different ways that I find half the enjoyment of writing Ruby. Like, it was one of those thi…

I respect that perspective. I both love and often avoid Ruby precisely because of this. But even if I don't use Ruby much day to day, I really appreciate what it taught me (Rails, too) and the fun I had writing it.

Post by ufuk » Tue, Nov 24, 2020, 10:19 PM UTC

d3nj4l wrote: post #56

ufuk wrote: post #29

Earlier quoted context omitted.

Ultimately, the goal is for Tapioca to replace all `srb rbi` tooling and `sorbet-rails`. Right now, we exclusively use Tapioca for gem RBIs and we don't use any `srb rbi` tooling at Shopify. That works perfectly fine, but you don't get any `sorbet-typed` RBIs, which, right now is not a concern for us. The DSL generators are not 100% complete to fully replace `sorbet-rails` right now, but we are preparing a 1.0 releas…

One of the challenges sorbet-rails faced [1] was with the usage of method_missing in certain places. The one that bit me was Rails automatically piping a class method from Model into the Model's CollectionProxy, effectively making class methods into scopes. We use this pretty extensively at work for complex scopes, so this is one of the reasons I've not been able to get complete buy-in for sorbet. Is that better in t…

I am afraid that is a shared concern for what Tapioca is doing as well. There are ways of mitigating that concern, by, for example, lifting all static methods on a model to be methods on the collection proxy in RBI files. This is certainly doable, and we are less interested in the correct signatures for such methods than having the method definitions in place, in the first place. On the other hand, we also have some Sorbet feature ideas that we want to experiment with where we might be able to annotate that a certain type delegates all missing methods to another type, for example.

This is indeed a problem in our codebase as well, and so far our team has been suggesting that people add shim (i.e. manual) RBI definitions for the methods that they find are missing from the types they've expected them on. This is a good stop-gap measure to solve a problem that is not very common with an easy solution to implement.

Re: Static Typing for Ruby: Adopting Sorbet at Scale

Re: Static Typing for Ruby: Adopting Sorbet at Scale