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.
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.
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.
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.
RBS and type files on the side were really hotly debated for a while and the core team settled on this as a way to not break the existing parser among other reasons.
While I don't 100% agree with them I have faith that Matz and the team make the decisions they do based on impact and what they see in the community.
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.
Soutaro is indeed a code member of the Ruby team, he also happens to work at Square. Soutaro is also one of the main contributors to RBS and helped define that standard.
He was going to keynote on this at RubyKaigi this year until it was cancelled, and had a talk at RubyConf as well on this.
That's correct. Sorbet currently uses RBI but after meeting with core they standardized on RBS and are migrating to present a more unified front and enable easier development of type checking libraries on top of it.
Very little of this will need to be written by hand. The underlying tech is pretty decent at guessing types, the idea is that if it's not quite specific enough you adjust it, but it should otherwise be transparent.
It is, and checkers like Steep and Sorbet can infer these types. We're currently playing with the idea of deriving from documentation like YARDoc as well.
This. RBS is the underlying language for defining type checkers. Sorbet and Steep both utilize it, and this allows future type checkers to evolve from a known-base instead of having to reinvent everything.
It's also a perniciously hard problem I'm very far from solving well quite yet.