You touch on an important difference between languages. A lot of existing tooling in this space focuses on static languages, exactly because there are existing

You touch on an important difference between languages. A lot of existing tooling in this space focuses on static languages, exactly because there are existing tools that you can build on to get something implemented more quickly. But, very few of those existing tools work for multiple static languages. LSP does, in that it provides a standard data API that all of the language-specific tools can implement — but you still have to implement the concepts once for each language that you want to support. There are relatively fewer existing tools in this space for dynamic languages. (Sorbet etc for Ruby are good examples of ones that do exist.) The ones that do require a fair bit of effort to implement, because you can't piggy-back on existing bits of a compiler, since there isn't one! (The analogous parts of a runtime interpreter tend to be much harder to piggy-back on for analysis purposes, since they all have a deeply ingrained assumption that you're in the middle of trying to execute the code.) So, the end result is that the “delta” between existing tools and what stack graphs provide is a bit bigger for a language like Python than (for instance) Go or Java. And that's a roundabout description of one of the reasons we had for targeting Python first!