Static Typing for Ruby: Adopting Sorbet at Scale
shopify.engineering
Static Typing for Ruby: Adopting Sorbet at Scale
1–10 of 72 posts
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#2The second part of this two-part blogpost is here: https://shopify.engineering/adopting-sorbet
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#3The second part of this two-part blogpost is here: https://shopify.engineering/adopting-sorbet
Happy to answer any questions here about our process, results or tools!
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#4I wish this had been available years ago!
I think Ruby was an excellent replacement for Lua to do ML, once Torch ran out of steam due to LuaJIT memory limitations. However, historically, MRI Ruby was slow and problematic.
Personally, I prefer Ruby to Python. Ruby is very close to Smalltalk, with some ideas from Perl and Lisp.
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#5Isn't crystal lang trying to do the same thing? Why not join forces?
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#6I wish this had been available years ago! I think Ruby was an excellent replacement for Lua to do ML, once Torch ran out of steam due to LuaJIT memory limitations. However, historically, MRI Ruby was slow and problematic. Personally, I prefer Ruby to Python. Ruby is very close to Smalltalk, with some ideas from Perl and Lisp.
> MRI Ruby was slow and problematic.
Why problematic?
On the slowness, I would agree that Ruby is slower than many languages, but as an interpreted language this is -up to a certain point- by design, or at least an accepted part of the trade-off one accepts when he takes a programming language. Moreover, Ruby's natural competitor is Python, not -say- Clojure; and I wouldn't that Ruby is significantly slower than Python.
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#7Isn't crystal lang trying to do the same thing? Why not join forces?
It's one thing to adopt a layer of static typing on top of your massive production codebase, it's another to switch languages entirely.
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#8Isn't crystal lang trying to do the same thing? Why not join forces?
Beyond the syntax looking a bit similar, Crystal is a very different language. Porting over a production application such as Shopify isn't something you do in an evening.
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#9The second part of this two-part blogpost is here: https://shopify.engineering/adopting-sorbet
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?
Re: Static Typing for Ruby: Adopting Sorbet at Scale
#10I wish this had been available years ago! I think Ruby was an excellent replacement for Lua to do ML, once Torch ran out of steam due to LuaJIT memory limitations. However, historically, MRI Ruby was slow and problematic. Personally, I prefer Ruby to Python. Ruby is very close to Smalltalk, with some ideas from Perl and Lisp.
> MRI Ruby was slow and problematic. Why problematic? On the slowness, I would agree that Ruby is slower than many languages, but as an interpreted language this is -up to a certain point- by design, or at least an accepted part of the trade-off one accepts when he takes a programming language. Moreover, Ruby's natural competitor is Python, not -say- Clojure; and I wouldn't that Ruby is significantly slower than Pyth…
It had lots of memory leaks. I love Ruby, and I used it anyway, but this bothered me a lot back in the mid-to-late 2000s.