-
I've been using Sorbet on a personal project (https://github.com/connorshea/vglist) for almost two years now, and it's been great (although I've had to build myself a lot of tooling for it over time).
I don't think I'll use the compiler (for now, at least), but I'm very interested in seeing how it grows over time :)
-
Judoscale
Save 47% on cloud hosting with autoscaling that just works. Judoscale integrates with Rails, Sidekiq, Solid Queue, and more to make autoscaling easy and reliable. Save big, and say goodbye to request timeouts and backed-up job queues.
-
(disclaimer: I work on the Sorbet team)
I think I understand GP's motivation: RBI files and RBS files are two different formats, and as a user of the language, people tend to want to use the officially blessed solution the language provides.
In case you weren't aware, parlour[1] is a popular open source project for working with RBI files. I believe it supports transparently converting between RBI files (Sorbet) and RBS files (Ruby 3).
There is also rbs_parser[2], a C++ parser for RBS files to convert them to RBI files, written by Shopify, a major user of Sorbet.
Stepping back: I haven't personally read many complaints from Sorbet users describing how the current state of RBI/RBS interop gets in the way of what they can actually do with Sorbet. Almost all the feature requests we get about Sorbet (both inside Stripe and outside) are for fixing bugs or implementing new language-level features. RBI files as implemented seem to work.
Sorbet already has an extensive set of RBI files covering the Ruby standard library (at least as good or better to my knowledge than any existing repository of types for RBS files), and there are plentiful tools for working with RBI files, listed here.[3]
If lack of first-party RBS support in Sorbet is holding you back from trying Sorbet, I'd strongly encourage you to give Sorbet a try anyways! Many people have shared great experiences adopting Sorbet in their Ruby codebases.
[1] https://github.com/AaronC81/parlour
[2] https://github.com/Shopify/rbs_parser
[3] https://sorbet.org/en/community
-
(disclaimer: I work on the Sorbet team)
I think I understand GP's motivation: RBI files and RBS files are two different formats, and as a user of the language, people tend to want to use the officially blessed solution the language provides.
In case you weren't aware, parlour[1] is a popular open source project for working with RBI files. I believe it supports transparently converting between RBI files (Sorbet) and RBS files (Ruby 3).
There is also rbs_parser[2], a C++ parser for RBS files to convert them to RBI files, written by Shopify, a major user of Sorbet.
Stepping back: I haven't personally read many complaints from Sorbet users describing how the current state of RBI/RBS interop gets in the way of what they can actually do with Sorbet. Almost all the feature requests we get about Sorbet (both inside Stripe and outside) are for fixing bugs or implementing new language-level features. RBI files as implemented seem to work.
Sorbet already has an extensive set of RBI files covering the Ruby standard library (at least as good or better to my knowledge than any existing repository of types for RBS files), and there are plentiful tools for working with RBI files, listed here.[3]
If lack of first-party RBS support in Sorbet is holding you back from trying Sorbet, I'd strongly encourage you to give Sorbet a try anyways! Many people have shared great experiences adopting Sorbet in their Ruby codebases.
[1] https://github.com/AaronC81/parlour
[2] https://github.com/Shopify/rbs_parser
[3] https://sorbet.org/en/community
-
Normally I wouldn't suggest Crystal [1] with Rails Shop given how different they are, but Stripe uses a tight subset of Ruby and Type Check everything I am wondering if they have ever looked at Crystal and what are their thoughts on it.
>Architected this way, the Sorbet Compiler turns Ruby into a language for writing Ruby native extensions! Instead of having to write C, C++, Rust, or some other compiled language to write native extensions, people can continue to write Ruby but gain the benefits of native compiled speeds.
To me this is the biggest feature that could impact the whole Ruby Ecosystem. Along with another Ruby JIT that is currently being tested at Shopify.
[1] https://crystal-lang.org
-
We're reluctant to completely fork the language. We benefit from so many open source tools, technologies, and libraries built around Ruby. For example: we've built:
- A type checker
- LSP-based editor tooling
- A compiler
But we haven't:
- implemented our own GraphQL, protobuf, gRPC, or JSON libraries
- built a Ruby debugger or debug protocol adapter
- built custom performance monitoring tools
- etc.
There might come a time when it makes sense to fork the language, but we've been very reluctant to do so from the start, because we know what we'd be throwing away. "Compatible with Ruby" has been an explicit design principle of Sorbet from the start:
https://github.com/sorbet/sorbet/#sorbet-user-facing-design-...
-
> Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post.
I'm currently working on Polyphony [0], a Ruby gem for writing highly-concurrent Ruby apps. It uses Ruby fibers under the hood, and does I/O using io_uring (on Linux, there is also a libev-based backend).
[0] https://github.com/digital-fabric/polyphony
