4 ms·

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

by jez 5y ago

pxeger1 5y ago
I'm just wondering why this wasn't open-source to start with
chucke 5y ago
when shall we expect RBS support?
ksec 5y ago
I know Shopify are using it [1], Do you know if Github or Basecamp are using it too? [1] https://twitter.com/rafaelfranca/status/1479259699694477312 https://twitter.com/rafaelfranca/status/1479259699694477312
- jez 5y ago
  I haven't heard anything from GitHub one way or another about whether they use Sorbet. I'd be extremely surprised if Basecamp was using it, as DHH has always been particularly opposed to types, but again, I haven't heard anything one way or another from them.
stanislavb 5y ago
Thanks for all the work! I've been wondering, are we to expect v1.0 at some point or we'll rely on daily/hourly new versions/updates?
- jez 5y ago
  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] flag, which will attempt to insert `T.unsafe(...)` in places in the program where there was a type error. Then in places where we improved Sorbet so that it no longer thought something was untyped, and started reporting errors downstream, you could run `bundle exec srb tc --autocorrect --suggest-unsafe` once after upgrading, and commit or delete the autocorrects as desired. It isn't a goal to have some sort of v1.0 milestone where new releases will not introduce type errors to a codebase that doesn't have any, which is I think what you're asking about. [1]: https://github.com/sorbet/sorbet/blob/master/main/options/options.cc#L473 https://github.com/sorbet/sorbet/blob/master/main/options/op... (edited to clarify phrasing in response to child comment)
  - jrochkind1 5y ago
    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 of a v1.0 release. That surprises me enough that I had to read it a couple times to make sure I was understanding how all the "not"s came out. I'd think that would be a thing you would straightforwardly want out of at type checker, the thing you said you don't have a plan or desire for. I'm interested in hearing more about why not, here or a link to somewhere else.
    - __s 5y ago
      The "not" is that they want freedom to make the type checker more strict, ie expand it to detect type errors it failed to detect previously
    - jez 5y ago
      Here's an example PR from a few days ago where someone contributed an improvement to the type definitions Sorbet maintains for the standard library: https://github.com/sorbet/sorbet/pull/5024 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%3ASig%0A%0Asig%20%7Bparams%28x%3A%20%7Bkey1%3A%20Integer%7D%29.void%7D%0Adef%20foo%28x%29%0A%20%20x%5B%3Akey2%5D%20%23%20no%20error!%0Aend 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.
bitwize 5y ago
Any chance of this becoming supported in VSCodium?
- jez 5y ago
  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.
  - bitwize 5y ago
    Yeah, VSCodium is just a build of the open-source VSCode base, it just can't connect to Microsoft's extension store because that's reserved for Microsoft's proprietary build. It should have the same APIs. I just wondered if the maintainers would officially support this use case. I'm not a VSCode user, but I do not trust Microsoft to dominate the entire dev tool ecosystem, and a stronger alternative base built around VSCodium would be a good thing.
    - teaearlgraycold 5y ago
      You can download the extension off of the official VSCode extension store in a web browser and install it manually in VSCodium.
pqdbr 5y ago
Is there official support for Sublime Text 3? I tried making it work a while ago and it wasn't easy to get it running.
- jez 5y ago
  We don't have anything custom on our end, but Sorbet implements the Language Server Protocol which it looks like Sublime Text 3 supports: https://lsp.sublimetext.io/language_servers/#sorbet https://lsp.sublimetext.io/language_servers/#sorbet These docs seem to even already have a snippet you should be able to add to your config to integrate Sorbet with Sublime Text 3.
square_usual 5y ago
Two questions (sorry if that's too much): 1. Sorbet isn't really great to use with Rails. I tried it out about a year ago - a few things might've changed but from scanning the relevant gems I think this broadly still applies. I used sorbet-rails but there were still a bunch of rough edges, eg. with using a class method on a model as a scope. The general theme was that Rails was doing quite a few things that make it super hard to type. ex - look at what it takes to do a type-safe pluck with sorbet-rails, and I don't think doing a typesafe select with association columns is even supported. Is there any acknowledgement of this from the Sorbet team itself, and will there be more to make the Sorbet with Rails experience better? 2. I'm really excited for the future of the Sorbet compiler. Like above, is there any work on making the AOT compiler work better with Rails?
- zomgwat 5y ago
  Regarding Sorbet and Rails, I recommend Tapioca [1]. The Rails app that I worked on had a few edge cases Tapioca didn't cover so I wrote a simple script to load the Rails app and generate RBI files (e.g. generate RBI definitions for fixture methods in ApplicationTestCase). The Tapioca codebase helped provide a path for that [2]. Tapioca also continues to add to their DSL compilers. The work to integrate Sorbet paid off very quickly. Also, T::Enum and T::Struct are handy in any Ruby codebase. [1] https://github.com/Shopify/tapioca https://github.com/Shopify/tapioca [2] https://github.com/Shopify/tapioca/tree/main/lib/tapioca/compilers/dsl https://github.com/Shopify/tapioca/tree/main/lib/tapioca/com...
- jez 5y ago
  1. I don’t know much about using Sorbet with Rails, but I do know that almost every major user of Sorbet that isn’t Stripe is using Sorbet with Rails! You might want to reach out in the #rails channel on our Sorbet Slack[1] for more? 2. Our focus for the Sorbet Compiler has always been more inward focused than Sorbet, so we focused pretty much exclusively on features that make the compiled code run fast on Stripe’s codebase. But you might be curious to read more about YJIT, the JIT compiler that was recently merged into Ruby 3.1—it’s being primarily developed by a team at Shopify where Rails performance is the highest priority. [1] https://sorbet.org/slack https://sorbet.org/slack
- 5y ago
bilekas 5y ago
This might be a dumb question but is there a chosen license for the this source ?
- jez 5y ago
  We open sourced it by merging it into the Sorbet repo, under which all code is Apache 2.0 licensed: https://github.com/sorbet/sorbet/blob/master/LICENSE https://github.com/sorbet/sorbet/blob/master/LICENSE
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

by jez 5y ago

Happy to answer any questions about Sorbet, the VS Code extension, or anything else you're curious about!

pxeger1 5y ago

I'm just wondering why this wasn't open-source to start with

chucke 5y ago

when shall we expect RBS support?

ksec 5y ago

I know Shopify are using it [1], Do you know if Github or Basecamp are using it too? [1] https://twitter.com/rafaelfranca/status/1479259699694477312 https://twitter.com/rafaelfranca/status/1479259699694477312

jez 5y ago
I haven't heard anything from GitHub one way or another about whether they use Sorbet. I'd be extremely surprised if Basecamp was using it, as DHH has always been particularly opposed to types, but again, I haven't heard anything one way or another from them.

stanislavb 5y ago

Thanks for all the work! I've been wondering, are we to expect v1.0 at some point or we'll rely on daily/hourly new versions/updates?

jez 5y ago
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] flag, which will attempt to insert `T.unsafe(...)` in places in the program where there was a type error. Then in places where we improved Sorbet so that it no longer thought something was untyped, and started reporting errors downstream, you could run `bundle exec srb tc --autocorrect --suggest-unsafe` once after upgrading, and commit or delete the autocorrects as desired. It isn't a goal to have some sort of v1.0 milestone where new releases will not introduce type errors to a codebase that doesn't have any, which is I think what you're asking about. [1]: https://github.com/sorbet/sorbet/blob/master/main/options/options.cc#L473 https://github.com/sorbet/sorbet/blob/master/main/options/op... (edited to clarify phrasing in response to child comment)
- jrochkind1 5y ago
  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 of a v1.0 release. That surprises me enough that I had to read it a couple times to make sure I was understanding how all the "not"s came out. I'd think that would be a thing you would straightforwardly want out of at type checker, the thing you said you don't have a plan or desire for. I'm interested in hearing more about why not, here or a link to somewhere else.
  - __s 5y ago
    The "not" is that they want freedom to make the type checker more strict, ie expand it to detect type errors it failed to detect previously
  - jez 5y ago
    Here's an example PR from a few days ago where someone contributed an improvement to the type definitions Sorbet maintains for the standard library: https://github.com/sorbet/sorbet/pull/5024 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%3ASig%0A%0Asig%20%7Bparams%28x%3A%20%7Bkey1%3A%20Integer%7D%29.void%7D%0Adef%20foo%28x%29%0A%20%20x%5B%3Akey2%5D%20%23%20no%20error!%0Aend 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.

bitwize 5y ago

Any chance of this becoming supported in VSCodium?

jez 5y ago
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.
- bitwize 5y ago
  Yeah, VSCodium is just a build of the open-source VSCode base, it just can't connect to Microsoft's extension store because that's reserved for Microsoft's proprietary build. It should have the same APIs. I just wondered if the maintainers would officially support this use case. I'm not a VSCode user, but I do not trust Microsoft to dominate the entire dev tool ecosystem, and a stronger alternative base built around VSCodium would be a good thing.
  - teaearlgraycold 5y ago
    You can download the extension off of the official VSCode extension store in a web browser and install it manually in VSCodium.

pqdbr 5y ago

Is there official support for Sublime Text 3? I tried making it work a while ago and it wasn't easy to get it running.

jez 5y ago
We don't have anything custom on our end, but Sorbet implements the Language Server Protocol which it looks like Sublime Text 3 supports: https://lsp.sublimetext.io/language_servers/#sorbet https://lsp.sublimetext.io/language_servers/#sorbet These docs seem to even already have a snippet you should be able to add to your config to integrate Sorbet with Sublime Text 3.

square_usual 5y ago

Two questions (sorry if that's too much): 1. Sorbet isn't really great to use with Rails. I tried it out about a year ago - a few things might've changed but from scanning the relevant gems I think this broadly still applies. I used sorbet-rails but there were still a bunch of rough edges, eg. with using a class method on a model as a scope. The general theme was that Rails was doing quite a few things that make it super hard to type. ex - look at what it takes to do a type-safe pluck with sorbet-rails, and I don't think doing a typesafe select with association columns is even supported. Is there any acknowledgement of this from the Sorbet team itself, and will there be more to make the Sorbet with Rails experience better? 2. I'm really excited for the future of the Sorbet compiler. Like above, is there any work on making the AOT compiler work better with Rails?

zomgwat 5y ago
Regarding Sorbet and Rails, I recommend Tapioca [1]. The Rails app that I worked on had a few edge cases Tapioca didn't cover so I wrote a simple script to load the Rails app and generate RBI files (e.g. generate RBI definitions for fixture methods in ApplicationTestCase). The Tapioca codebase helped provide a path for that [2]. Tapioca also continues to add to their DSL compilers. The work to integrate Sorbet paid off very quickly. Also, T::Enum and T::Struct are handy in any Ruby codebase. [1] https://github.com/Shopify/tapioca https://github.com/Shopify/tapioca [2] https://github.com/Shopify/tapioca/tree/main/lib/tapioca/compilers/dsl https://github.com/Shopify/tapioca/tree/main/lib/tapioca/com...
jez 5y ago
1. I don’t know much about using Sorbet with Rails, but I do know that almost every major user of Sorbet that isn’t Stripe is using Sorbet with Rails! You might want to reach out in the #rails channel on our Sorbet Slack[1] for more? 2. Our focus for the Sorbet Compiler has always been more inward focused than Sorbet, so we focused pretty much exclusively on features that make the compiled code run fast on Stripe’s codebase. But you might be curious to read more about YJIT, the JIT compiler that was recently merged into Ruby 3.1—it’s being primarily developed by a team at Shopify where Rails performance is the highest priority. [1] https://sorbet.org/slack https://sorbet.org/slack
5y ago

bilekas 5y ago

This might be a dumb question but is there a chosen license for the this source ?

jez 5y ago
We open sourced it by merging it into the Sorbet repo, under which all code is Apache 2.0 licensed: https://github.com/sorbet/sorbet/blob/master/LICENSE https://github.com/sorbet/sorbet/blob/master/LICENSE
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]