baweaver

That's definitely one of the core motivations is to capture, contextually, as much of an upgrade as possible in hard code.

It's also a perniciously hard problem I'm very far from solving well quite yet.

The testing utilities are also great. The difficulty, I'd say, is inherit to working with ASTs and simplifying it is hard. They tried with Node Pattern, synvert tried with NQL, and I wanted to try with pattern matching and potentially more in-Ruby approaches.

Nothing particularly wrong with any of them, but trying to sort out what's not matching and getting an answer for now "close" a node was is a bit involved. Go far enough down that hole and you hit tree edit distance and Zhang Sha Sha algorithms.

Consider it a sandbox and a more minimal syntax around what Rubocop already does well. If anything I may try and upstream some of it later after it takes more shape.

It's also used to wrap a lot of AST tools for a talk I have next week, hence the earlier release even if it's fairly simple.

To be fair I didn't post it :)

Yeah, it's still very very early in the process and I released it as I have a talk at Ruby Kaigi going over some of how this works next Tuesday, so I wanted something out even if it's simple for now.

You know I'm friends with @bbatsov right? That's reaching pretty far. I've actively funded the maintainers in the past as well, doesn't mean I agree with everything or every name, but I respect their work.

Agreed. Currently at Square so watching some of this.

The best path forward will be a lot of discussion, especially around learnings with production codebases where possible.

Personally I prefer inline annotations, but want to explore the possibilities of both and see what comes of it. I've written on Sorbet in the past and have used it on a few toy projects.

Also working on some analysis documentation comparing the two if you'd be interested in chatting later. Feel free to DM @keystonelemur on Twitter.

That's definitely fair, and probably a large reason why they're so paranoid about repeating that.

The intention right now is for the StdLib to provide known types to build off of written in RBS. There's no requirement to use them necessarily.

Steep and Sorbet are second-level, they build off of RBS. Matz has mentioned offhandedly in conversations I'd had with him in the past that there's a ton more in store with RBS beyond just type checking, so we'll see where they go with it.

As far as YARDoc I've been eyeing that one for a while now since I first heard about Steep at a Braintree Ruby meetup before Soutaro was at Square. We're still talking about what and how as far as that one.

Yep, and glad to see the work Stripe is doing on things as well. Always enjoy seeing where you all are going.

Soutaro has been great to work with over here (Square), and he has a ton of really amazing things coming soon that we're working on OSS'ing later.

Yeah, there was a ton of discussion on this in the Ruby bugtracker and at core meetings. Matz is very sensitive to breaking the language with Ruby 3 and the core team is doing their best to ensure an easy transition.

Sorbet was written in C++ and is a great piece of work, Stripe did a great job with it. It does have some issues as soon as someone gets into the magic weeds with metaprogramming like Rails does.

Disclaimer: Working at Square, have friends at Stripe, enjoy both type checkers.

It was, and I was around during one of his discussions on that at RubyConf last year. It's a very valid concern and Matz is very sensitive to it. There are a lot of things he's joked about removing or changing but won't because of those reasons.

If you take a look at his keynote video he says quite a bit on this too.

Matz had mentioned this as a key reason he was interested in working on this, as well as a "language server" with a lot of really interesting features like what JS/TS has with VS Code.

I had the good fortune to hear him talk about it at length at a conference a while ago and there's all types of fun stuff on the way.

That would be correct.