Ufuk Kayserilioglu

So it's able to parse and understand Ruby and in some ways simplify the Ruby language. So it can do those kinds of static analysis without necessarily running your code. Well, I shouldn't say necessarily. It doesn't run your code at all. So in that way, it's a static type checker. And it's built to be blazingly fast.

So it's able to parse and understand Ruby and in some ways simplify the Ruby language. So it can do those kinds of static analysis without necessarily running your code. Well, I shouldn't say necessarily. It doesn't run your code at all. So in that way, it's a static type checker. And it's built to be blazingly fast.

So it can parse, understand, and type check our whole code base, the code base, the core code base that I've been talking about of about 30,000 files in a matter of like 10, 15 seconds. And it was built with intentionally to be fast and to be as safe as possible when you're developing Ruby. Sorbet was amazing. open sourced about a year ago. So it was June, 2019 when it was open sourced.

So it can parse, understand, and type check our whole code base, the code base, the core code base that I've been talking about of about 30,000 files in a matter of like 10, 15 seconds. And it was built with intentionally to be fast and to be as safe as possible when you're developing Ruby. Sorbet was amazing. open sourced about a year ago. So it was June, 2019 when it was open sourced.

But it was being developed by Stripe for about, I think, two years before that. And by the time I joined Shopify, we had already gotten on the early release beta program where they were doing like code sharing with Shopify. So we were able to start our adoption earlier than when it was initially open source.

But it was being developed by Stripe for about, I think, two years before that. And by the time I joined Shopify, we had already gotten on the early release beta program where they were doing like code sharing with Shopify. So we were able to start our adoption earlier than when it was initially open source.

Then afterwards, Stripe also got like a few other companies that were interested into the public beta program as well. But so that's why our story is a little bit different because we ended up solving some of the problems that people who might want to adopt Sorbet don't have to solve right now because it's a much more mature product.

Then afterwards, Stripe also got like a few other companies that were interested into the public beta program as well. But so that's why our story is a little bit different because we ended up solving some of the problems that people who might want to adopt Sorbet don't have to solve right now because it's a much more mature product.

But back when we were trying to adopt it on our code base, it was mostly a tool that was built with the Stripe code base in mind. And I can't talk too much about what Stripe code base is like, because I don't know, but from our understanding is it doesn't use Rails. It tries to use as little meta programming as possible.

But back when we were trying to adopt it on our code base, it was mostly a tool that was built with the Stripe code base in mind. And I can't talk too much about what Stripe code base is like, because I don't know, but from our understanding is it doesn't use Rails. It tries to use as little meta programming as possible.

So they're like really big on intention revealing code and not so much meta programming. So Sorbet was the right tool for them and they were developing to solve their own solutions, obviously initially, but because our code base is Rails, which already has a lot of meta programming. So meta programming brings in a lot of dynamic methods that can only be seen when you're running the code, right?

So they're like really big on intention revealing code and not so much meta programming. So Sorbet was the right tool for them and they were developing to solve their own solutions, obviously initially, but because our code base is Rails, which already has a lot of meta programming. So meta programming brings in a lot of dynamic methods that can only be seen when you're running the code, right?

So, so there are lots of methods that you don't see, for example, on active record models, you don't see all the attributes, right? Because the attributes are created at runtime. All the methods that relate that are related to attributes are created at runtime. after Rails has had a chance to introspect your database tables.

So, so there are lots of methods that you don't see, for example, on active record models, you don't see all the attributes, right? Because the attributes are created at runtime. All the methods that relate that are related to attributes are created at runtime. after Rails has had a chance to introspect your database tables.

Obviously, that's a big problem for Sorbet because it looks at the code, tries to understand it statically, and it says, oh, this model has no methods. And so in another part of the code base, when you're trying to do a shop.something, Sorbet says, oh, like shop doesn't have this method. So that ends up being a problem.

Obviously, that's a big problem for Sorbet because it looks at the code, tries to understand it statically, and it says, oh, this model has no methods. And so in another part of the code base, when you're trying to do a shop.something, Sorbet says, oh, like shop doesn't have this method. So that ends up being a problem.

So one of the first things we had contributed to the Sorbet codebase was a way to have the static type checker understand some of the meta programming concepts. So our initial idea was that we could write scripts in Ruby and Sorbet could basically execute them so that the scripts could generate what methods would exist if the code had ran, but it would still be a static type checker.

So one of the first things we had contributed to the Sorbet codebase was a way to have the static type checker understand some of the meta programming concepts. So our initial idea was that we could write scripts in Ruby and Sorbet could basically execute them so that the scripts could generate what methods would exist if the code had ran, but it would still be a static type checker.

It kind of tided us over that solution for a while, but it ended up slowing down the type checking process a lot, but at least it allowed us to do our own like initial adoption at the time. Another problem as we're adopting was that all the types that are coming from our gem dependencies. So our core monolith has about 400 gem dependencies, which is already like a huge maintenance problem, right?

It kind of tided us over that solution for a while, but it ended up slowing down the type checking process a lot, but at least it allowed us to do our own like initial adoption at the time. Another problem as we're adopting was that all the types that are coming from our gem dependencies. So our core monolith has about 400 gem dependencies, which is already like a huge maintenance problem, right?