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.
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.
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.
Ruby 1.8 to 1.9 was very painful, I am not sure why it was more succesful than Python 2->3, I'm not sure it "deserved" to be or was any less painful on it's face. It easily could have been just as disastrous. So also informed by that; ruby hasn't done anything nearly as painful since.
But that applies to making it so old code does not work in the new version of the language. Nobody expects all new code to work in the old version of the language. Ruby adds new features including syntax that won't properly parse in old interpreters all the time. It's not clear to me why inline type definitions couldn't be such.
Matz often cited the "carrot" of much better performance on 1.9 as a reason for the successful transition.
Python3 didn't offer much over python2, so people just saw the downsides, while ruby pushed people to upgrade with the promise that their efforts would gain them better performance and/or save money.
I expect most ruby projects only have rails as its core dependency with all other gems being small utility libraries that can be easily updated and replaced. Python gets used for such a wide variety of things.
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.
It's also a perniciously hard problem I'm very far from solving well quite yet.