11–20 of 88 posts
Thank you - Great looking release! Other Ruby extensions seemed like afterthoughts or incomplete efforts. Does Stripe use Ruby enough internally to "bootstrap" this from the ground up?
Earlier quoted context omitted.
Our goal with new Sorbet versions is to break things where it makes sense (fix bugs, improve types for the standard library) which sometimes introduces new type errors in projects using Sorbet. But wherever possible, we try to build autocorrects that allow for fixing or silencing those breakages. One little known feature here that works mostly well right now but could definitely be better is the `--suggest-unsafe` [1…
Thanks for the info! I don't use sorbet myself yet (although I am a ruby user), so this is not coming from any kind of educated basis, just an outside observer being curious, but I'm curious: > We don't currently have a plan or a desire to get to a state where upgrading to a new Sorbet version will not introduce new errors on a codebase that previously type checked, which is what I think you might imply you want out…
Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!
Earlier quoted context omitted.
Our goal with new Sorbet versions is to break things where it makes sense (fix bugs, improve types for the standard library) which sometimes introduces new type errors in projects using Sorbet. But wherever possible, we try to build autocorrects that allow for fixing or silencing those breakages. One little known feature here that works mostly well right now but could definitely be better is the `--suggest-unsafe` [1…
Thanks for the info! I don't use sorbet myself yet (although I am a ruby user), so this is not coming from any kind of educated basis, just an outside observer being curious, but I'm curious: > We don't currently have a plan or a desire to get to a state where upgrading to a new Sorbet version will not introduce new errors on a codebase that previously type checked, which is what I think you might imply you want out…
https://github.com/sorbet/sorbet/pull/5024
By adding those type definitions, any downstream projects using Sorbet that happened to use those definitions incorrectly will start to see new type errors.
Here's another example:
https://sorbet.run/#%23%20typed%3A%20true%0Aextend%20T%3A%3A...
This example shows a bug in how Sorbet handles shape types, that we definitely want to fix in the future but haven't had the time to yet. When we fix that, any project using shape types incorrectly will suddenly have new type errors.
Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!
Any chance of this becoming supported in VSCodium?
I personally find adding types inside ruby files to be unreadable. Well, this is just my personal opinion.
Earlier quoted context omitted.
Any chance of this becoming supported in VSCodium?
I don't see why it wouldn't be supported! If the APIs are the same as VS Code's APIs, you should be able to build the VS Code extension from source and load it into VSCodium at your convenience.
Can someone explain how this fits into .rbs files? Would sorbet support adding/reading types as part of .rbs files in the future. I personally find adding types inside ruby files to be unreadable. Well, this is just my personal opinion.
https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet
tl;dr:
- RBS files are what Ruby 3 uses to describe types in separate files
- RBI files are what Sorbet uses to describe types in separate files
- Sorbet invented its RBI file syntax before RBS files existed. RBI files use the same syntax for types and signatures as in type annotations that live inside `*.rb` source code with Sorbet.
- We've been meaning to add support to Sorbet to consume both RBI files and RBS files, but we haven't had a chance to get around to it.
If someone beat us to it and implemented support for RBS files in Sorbet that would be amazing! Shopify took an early stab at implementing an RBS parser in C++ for performance[1], but I'm not sure what the status of it is today.
Thank you - Great looking release! Other Ruby extensions seemed like afterthoughts or incomplete efforts. Does Stripe use Ruby enough internally to "bootstrap" this from the ground up?
Stripe has a huge existing Ruby codebase that powers a lot of the dashboard and more. But there’s also a push towards Java for new services. Notably, Stripe does not use Ruby on Rails: instead there’s a few homegrown frameworks used for routing, storing data in a database, etc.
Will Sorbet and this extension allow for autocomplete of non-Sorbet signed methods? Or does it only expose methods with a signature?
If Sorbet knows the type of the receiver of the method call, it will suggest completion results, regardless of whether any of the suggestions themselves have sigs, or whether you're inside a method with a signature. But without any sigs, there aren't going to necessarily be as many opportunities for Sorbet to know the type of the receiver as there would be with sigs. Here's an example https://sorbet.run/#%23%20typed%…