4 ms·

Happy to answer any questions here about our process, results or tools!

by ufuk 6y ago

stu2b50 6y ago
Having used Sorbet, one thing immediately noticeable is that it's incredibly verbose due to needing to be valid ruby syntax. Was there any developer pushback on that? Also, maybe I missed it, but Sorbet has a very fleshed out plugin for VSCode but that's about it. How was the experience getting people who don't use VSCode to integrate it into their workflow?
- ufuk 6y ago
  There was definitely some general suspicion when we first introduced Sorbet. However, there were also some early adopters who didn't mind the syntax but really wanted the benefits. That's why we didn't push for types adoption, we allowed teams to adopt (or not) at their own pace. Once people saw the benefits, they wanted more of it. Syntax also stopped being a huge concern. Quoting from the blogpost: > - Developers get used to Sorbet syntax over time > ... > Our main observation is that developers enjoy Sorbet more as the typing coverage increases. On the editor integration, the funny thing is that VSCode is the only editor that needs a special extension to integrate with Sorbet. The way Sorbet supports editors is via the built-in Language Server Protocol (LSP) mode which can be used with any LSP plugin for any editor. I know people who are using it with Vim, Sublime Text, etc. Integration is, in a nutshell, running `srb tc --lsp` as a subcommand and piping data in/out via stdin/out. Our tool Spoom actually uses the same LSP mode to provide extra developer tools and analysis on top of Sorbet.
  - darkdimius 6y ago
    Dmitry here, from Stripe. One of founding members of Sorbet(though I no longer work on it anymore). Story that Ufuk shares is common. We saw this process repeat in many companies, Stripe, Shopify and many others - folks are initially bothered with verbosity of `sig` syntax, but as the company starts using it in practice stop being bothered pretty quikcly. It happens even faster now that IDE integration allows to auto-complete entire signature and can in most cases correctly guess the types of arguments & result type. You rarely type `sig`s yourself. The common internal asks at Stripe are about even better IDE support, new features & etc and that's where most of investments are. Well, and and obviously performance. Sorbet was already very fast and we intend to keep it fast as our huge codebase grows.
coreyja 6y ago
Do you have any tips or tricks for migrating a Rails app from Sorbet `srb rbi` generated files to one using Tapioca? I was unsure exactly which bits of Sorbet rbi were still required with tapioca https://github.com/Shopify/tapioca/issues/114 https://github.com/Shopify/tapioca/issues/114 We are currently using `sorbet-rails` but it appears Tapioca would be a replacement for that as well, is that correct?
- ufuk 6y ago
  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 release of the gem that should be able to do that.
  - coreyja 6y ago
    Thanks for the reply! > but you don't get any `sorbet-typed` RBIs, which, right now is not a concern for us. Ahh ok! I think this might have been a bit I missed, cause I was commonly trying to do both which likely caused issues for me. > The DSL generators are not 100% complete to fully replace `sorbet-rails` right now, but we are preparing a 1.0 release of the gem that should be able to do that. Will keep my eyes open, thanks!
  - d3nj4l 6y ago
    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 tapioca? (Also: Thank you for sorbet! It's the biggest reason I continue to use Ruby for my personal projects.) 1: https://github.com/chanzuckerberg/sorbet-rails/issues/104 https://github.com/chanzuckerberg/sorbet-rails/issues/104

Happy to answer any questions here about our process, results or tools!

by ufuk 6y ago

Happy to answer any questions here about our process, results or tools!

Having used Sorbet, one thing immediately noticeable is that it's incredibly verbose due to needing to be valid ruby syntax. Was there any developer pushback on that? Also, maybe I missed it, but Sorbet has a very fleshed out plugin for VSCode but that's about it. How was the experience getting people who don't use VSCode to integrate it into their workflow?

ufuk 6y ago
There was definitely some general suspicion when we first introduced Sorbet. However, there were also some early adopters who didn't mind the syntax but really wanted the benefits. That's why we didn't push for types adoption, we allowed teams to adopt (or not) at their own pace. Once people saw the benefits, they wanted more of it. Syntax also stopped being a huge concern. Quoting from the blogpost: > - Developers get used to Sorbet syntax over time > ... > Our main observation is that developers enjoy Sorbet more as the typing coverage increases. On the editor integration, the funny thing is that VSCode is the only editor that needs a special extension to integrate with Sorbet. The way Sorbet supports editors is via the built-in Language Server Protocol (LSP) mode which can be used with any LSP plugin for any editor. I know people who are using it with Vim, Sublime Text, etc. Integration is, in a nutshell, running `srb tc --lsp` as a subcommand and piping data in/out via stdin/out. Our tool Spoom actually uses the same LSP mode to provide extra developer tools and analysis on top of Sorbet.
- darkdimius 6y ago
  Dmitry here, from Stripe. One of founding members of Sorbet(though I no longer work on it anymore). Story that Ufuk shares is common. We saw this process repeat in many companies, Stripe, Shopify and many others - folks are initially bothered with verbosity of `sig` syntax, but as the company starts using it in practice stop being bothered pretty quikcly. It happens even faster now that IDE integration allows to auto-complete entire signature and can in most cases correctly guess the types of arguments & result type. You rarely type `sig`s yourself. The common internal asks at Stripe are about even better IDE support, new features & etc and that's where most of investments are. Well, and and obviously performance. Sorbet was already very fast and we intend to keep it fast as our huge codebase grows.

coreyja 6y ago

Do you have any tips or tricks for migrating a Rails app from Sorbet `srb rbi` generated files to one using Tapioca? I was unsure exactly which bits of Sorbet rbi were still required with tapioca https://github.com/Shopify/tapioca/issues/114 https://github.com/Shopify/tapioca/issues/114 We are currently using `sorbet-rails` but it appears Tapioca would be a replacement for that as well, is that correct?

ufuk 6y ago
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 release of the gem that should be able to do that.
- coreyja 6y ago
  Thanks for the reply! > but you don't get any `sorbet-typed` RBIs, which, right now is not a concern for us. Ahh ok! I think this might have been a bit I missed, cause I was commonly trying to do both which likely caused issues for me. > The DSL generators are not 100% complete to fully replace `sorbet-rails` right now, but we are preparing a 1.0 release of the gem that should be able to do that. Will keep my eyes open, thanks!
- d3nj4l 6y ago
  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 tapioca? (Also: Thank you for sorbet! It's the biggest reason I continue to use Ruby for my personal projects.) 1: https://github.com/chanzuckerberg/sorbet-rails/issues/104 https://github.com/chanzuckerberg/sorbet-rails/issues/104