Ufuk Kayserilioglu

So a T untyped always returns a T untyped when you call a method on it and everything. So that kind of lessens the amount of strict typing that you're doing. You can opt into higher types, strictness levels in your files to prevent this. So you can opt into type strict, which will tell you if you're doing this unsafe calls and it will say, oh, you're actually calling into a method.

So a T untyped always returns a T untyped when you call a method on it and everything. So that kind of lessens the amount of strict typing that you're doing. You can opt into higher types, strictness levels in your files to prevent this. So you can opt into type strict, which will tell you if you're doing this unsafe calls and it will say, oh, you're actually calling into a method.

that doesn't have a type signature. So, you know, there's something wrong here. So go and add a type signature to this other method that you're calling to make sure that this file has a stricter type checking. So we didn't go that far in the dev code base. We wanted to see how much we could get with simple typing.

that doesn't have a type signature. So, you know, there's something wrong here. So go and add a type signature to this other method that you're calling to make sure that this file has a stricter type checking. So we didn't go that far in the dev code base. We wanted to see how much we could get with simple typing.

So there were still a few argument errors or no method errors that leaked in, but we were able to reduce those kinds of errors as well. But that's not the only thing we did. We also looked at if running type checks on CI had any effect on the CI success rate. So were there like any false positives that Sorbet was failing on that were breaking CI builds or vice versa?

So there were still a few argument errors or no method errors that leaked in, but we were able to reduce those kinds of errors as well. But that's not the only thing we did. We also looked at if running type checks on CI had any effect on the CI success rate. So were there like any false positives that Sorbet was failing on that were breaking CI builds or vice versa?

Were there any test failures that Sorbet wasn't catching? And we realized that Sorbet didn't have an effect either way. So it wasn't causing superior failures on CI, nor was it really missing anything. So there weren't really that many test failures that survey also didn't catch. But we also talked to the team. So I think that's one of the most interesting things we've done.

Were there any test failures that Sorbet wasn't catching? And we realized that Sorbet didn't have an effect either way. So it wasn't causing superior failures on CI, nor was it really missing anything. So there weren't really that many test failures that survey also didn't catch. But we also talked to the team. So I think that's one of the most interesting things we've done.

We talked to the team both before we started this experiment individually and talked to them after we finished this experiment. to see. So before we wanted to see how much they knew about Sorbet, how they felt about Sorbet, were they enthusiastic or did they have questions about its utility or not? So we compiled those.

We talked to the team both before we started this experiment individually and talked to them after we finished this experiment. to see. So before we wanted to see how much they knew about Sorbet, how they felt about Sorbet, were they enthusiastic or did they have questions about its utility or not? So we compiled those.

And then after we finished this experiment, we also asked them if they were using Sorbet type checking on their machines, if they were happy adding signatures to the codebase, or if they had problems having to deal with fixing signatures when they were factoring. So we were able to also get a qualitative feedback on how the team and how the developer happiness was impacted or not.

And then after we finished this experiment, we also asked them if they were using Sorbet type checking on their machines, if they were happy adding signatures to the codebase, or if they had problems having to deal with fixing signatures when they were factoring. So we were able to also get a qualitative feedback on how the team and how the developer happiness was impacted or not.

And we actually heard good things about that. So there was one person on the team who really didn't like signatures. They found it really distracting. One of the things about Sorbet signatures is because Sorbet is not integrated with the language. Obviously Ruby as a language doesn't support types. So you need to add a signature annotation on top of your method definitions.

And we actually heard good things about that. So there was one person on the team who really didn't like signatures. They found it really distracting. One of the things about Sorbet signatures is because Sorbet is not integrated with the language. Obviously Ruby as a language doesn't support types. So you need to add a signature annotation on top of your method definitions.

And that signature annotation is also Ruby code. So you do like a sig block. So you say sig and then you start a block and then you say params and you declare your parameters and their types. And then you do a dot returns and then you declare the type of your return. And then you can do more things in there as well.

And that signature annotation is also Ruby code. So you do like a sig block. So you say sig and then you start a block and then you say params and you declare your parameters and their types. And then you do a dot returns and then you declare the type of your return. And then you can do more things in there as well.

But obviously sometimes for a two or three line method, your signature can end up being five or six lines if it's doing something like non-trivial or if your types have like some generics or something. So some people actually find that. to their posts and sometimes distracting. So they say that it makes it hard to actually see the code.

But obviously sometimes for a two or three line method, your signature can end up being five or six lines if it's doing something like non-trivial or if your types have like some generics or something. So some people actually find that. to their posts and sometimes distracting. So they say that it makes it hard to actually see the code.

They end up seeing like all these signatures, but that person on the team actually developed like a few Vim configs to de-emphasize the signatures. So they basically turned the opacity on the signatures so that they look like comments, which they kind of are, right? Like, because that's the same thing with Yard definitions. So when you add type annotations in Yard comments, that's the same thing.

They end up seeing like all these signatures, but that person on the team actually developed like a few Vim configs to de-emphasize the signatures. So they basically turned the opacity on the signatures so that they look like comments, which they kind of are, right? Like, because that's the same thing with Yard definitions. So when you add type annotations in Yard comments, that's the same thing.