Stripe open sourced Sorbet today, a fast, powerful type checker for Ruby.
Here's the full blog post, Open-sourcing Sorbet: a fast, powerful type checker for Ruby.
Being a fan of TypeScript, I know people have all kinds of feels.
I wonder how rubyists on DEV feel about the project or static types. What say you devs? Yay or nay?
Thanks to my co-worker Denis Pasin for sharing this on our work Slack.
Top comments (33)
Too soon to have an opinion? :D
☝ This.
Being the first to use some technology very rarely will give a competitive advantage to your company.
But, I am happy that people are trying static types in Ruby, so the rest can learn if it's worth it or not. ;)
PR is already up LOL. I converted the entire ruby code base of DEV to Sorbet. 😜
I'd love to see how you got Sorbet to work with Rails. I just tried and it didn't pick up any of the columns on the models, so I had 1000s of errors (method not found when calling model columns). I couldn't find any documentation or any quick way to fix.
I was kidding about the PR. 😉 I'm still pretty new to Ruby.
There is a gem which create RBI files for ActiveRecord and URL helpers: github.com/chanzuckerberg/sorbet-r...
up until yesterday the sorbet-rails only supported Rails 5.2 -- but 0.2 release also supports 5.1 .. if you were having issues using it, i'd recommend bumping the version and tryin again
LOL
Il reword it to how to ruby devs feel about types in their code. 😎
I feel the same as I feel about adding static typing to other high level dynamic languages (see mypy for Python for example) that weren't designed with static typing in the first place: meh.
I'm not for it, nor against it.
In a "philosophical" sense one of the main choices a developer has when picking a language is if they want static or dynamic typing.
Typing annotation for dynamically typed languages feels both a patch and a useful addition, hence my meh.
I agree with @6temes here when he says that mindlessly adding types to bad code base does not improve such code. It makes the tool happy though, but that's another argument which is more about code quality and software design than typing.
:thumbs
So back in the old thread I kind of said “yeah, let’s go with typescript” but we haven’t had a ton of hard willpower to actually do much about it.
I think getting typed into the backend could definitely be a factor to help embrace types uniformly throughout. In the long run it seems like it could only help our overall code quality.
I’ll definitely be following this, thinking a lot about it, and be open to folks suggesting this as a path forward.
I think that it is often a mistake to associate code quality with tools. Code quality depends on the developers' quality. I have seen many teams racing to implement the next shiny technology in the hope that it will solve their problems when their main problem is the way they code.
Bad code with types is as bad (or worse) than a bad code without types.
But, yes. Types are convenient, and I hope that there is a good way to introduce them to Ruby, without compromising the natural expressiveness of the language.
I agree, which is why we haven’t rushed to adopt Typescript or other things mentioned here. But I do think it’s the kind of thing that definitely could improve code quality. I’m not itching to be super early adopters though either.
One thing I love and adore about the Ruby-community, is our willingness to go explore other languages and idioms, while the bringing the best stuff back to our own little ecosphere.
For Stripe to put all that effort into building a type checker for Ruby says something about how real of an issue it must have been for them, and I have the utmost respect for that.
I don't think this is something that I'd want to use in my own projects, however.
I see the lack of type checking as one of the core strengths of Ruby. How many times have we heard Sandi Metz referer to
is_a?(class)as a particularly pungent smell, and that our code shouldn't care about types and classes, but instead focus on what roles our objects are willing to play. We just want to send a message.With that said, I think it's fantastic that Stripe has chosen to open source Sorbet. It says a lot about the mentality and our willingness to share in the community, and I love that. I think Ruby has a bright future ❤️
Great comment :)
It's my first — so thank you 🙏
Thanks for chiming in and welcome to DEV!
Thank you so much, Nick! ✌️
I like the idea of types in Ruby, but I prefer steep's approach of having a separate .rbi file for the type signatures. Guess we'll have to wait and see which style is picked for Ruby 3!
An issue with this approach, just from a glance, is the same of documentation in a separate file: people have to keep the two files in sync. Knowing devs, they are going to do it for a while, and then forget about it.
BTW: Sorbet supports RBI: sorbet.org/docs/rbi
I'm still fairly new to ruby. Wasn't aware of steep. Thanks for sharing.
I think there's a lot of interest in this in the community. Task Rabbit, where I work, asked to be invited to the beta. I don't think most Ruby devs want a "Types First" workflow. Many of us came from Java to Ruby to get away from that. But the fact is, a ton of the production errors I've encountered over the past 10 years would be less likely with static type checking.
I think a lot of Rubyist will write the code fully dynamically and add the type annotations after the fact.
Curious how it works with code that is deliberately taking advantage of duck typing and/or metaprogramming.
My gut reaction to the 'sugar' that Sorbet adds to the language was pretty 'horrific'. Ruby tends towards having a clean development and reading story. Sorbet definitely muddys the waters here.
Saying that, having an optional type checker on a bigger Ruby (non Rails) code base (like what they have at Stripe), would be nice. I work a bit on the side on a substantially sized JRuby/Sinatra app and there are many times where we pull a release due to type like errors making their way into logs.
Sorbet could/would catch these easily and likely make the code base much easier to change quickly for new devs. Shrug only time will tell I guess but, honestly it's great that Stripe got this into a solid shape before letting it loose on the masses.
Nice! Although I'm going to wait until types are added in Ruby 3. I much prefer the syntax of the .rbi files to this
They support RBI apparently sorbet.org/docs/rbi
I'm a ruby newbie, so I wasn't aware they were bringing them directly to the language. Good to know.
I used to take a pretty hard like stance that I didn't want types in my Ruby. I like ducktyping and all that too much.
It's always felt to me like bolting something onto a language that was never meant to support it. Ruby is designed to embrace it's dynamic nature just seems opposed to the id a or typing.
But more recently I've come around a little bit. And Typescript is one of the things that's changed my mine. I 100% agree that types are awesome and I've been really interested in Rust and strong types.
And I don't think adding some type declarations is a bad idea, but I'm been hesitant since any bolted on types don't feel like a complete solution. But I think my realization was that just cause bolted on types don't provide perfect protection that doesn't mean they don't have some value.
So I haven't looked at Serbet at all, but there is significant interest in it at my day job. I'll probably take a look sometime soon, since it's released now. I'm not automatically on board, but I'm also not completely against it anymore!
If writing ruby but constrained by static types, just write in Crystal. It will likely be much more performant.
Looks like @palkan_tula did a write up on Sorbetting a gem. Thanks Vladimir!
Sorbetting a gem, or the story of the first adoption
Vladimir Dementyev ・ Jun 24 ・ 11 min read