Does that not also suggest (cautious, make sure we back it up with our actions) optimism about this acquisition? We're not breaking up the band. These tools will be in the same hands as before. And it would be extremely value-destructive to bring in a team like ours and then undermine what made us valued and successful.
The parser is not the hard part. The hard part is doing something useful with the parse trees. They even chose "oh is that all?" and a picture of a piece of cake as the teaser image for my Strange Loop talk on this subject!
I've been in the industry for similarly long, and I understand and sympathize with this view. All I can say is that _right now_, we're committed to maintaining our open-source tools with the same level of effort, care, and attention to detail as before. That does not change with this acquisition. No one can guarantee how motives, incentives, and decisions might change years down the line. But that's why we bake optionality into it with the tools being permissively licensed. That makes the worst-case scenarios have the shape of "fork and move on", and not "software disappears forever".
> My understand is Astral's focus for ty has been on making a good experience for common issues, whereas they plan for very high compliance but difficult or rare edge cases aren't are prioritized.
I would say that's true in terms of prioritization (there's a lot to do!), but not in terms of the final user experience that we are aiming for. We're not planning on punting on anything in the conformance suite, for instance.
If you run a type checker like ty or pyright they're not decorative — you'll get clear diagnostics for that particular example [1], and any other type errors you might have. You can set up CI so that e.g. blocks PRs from being merged, just like any other test failure.
If you mean types not being checked at runtime, the consensus is that most users don't want to pay the cost of the checks every time the program is run. It's more cost-effective to do those checks at development/test/CI time using a type checker, as described above. But if you _do_ want that, you can opt in to that using something like beartype [2].
There have been some early proposals to add something like that, but none of them have made it very far yet. As you might imagine, it's a hard problem!
There was a hang/performance bug [1, 2] that was reported just after the beta release, which we've since fixed [3]. You might try seeing if we get through your entire project now?
(And as an aside, there _is_ a verbose mode: if you add `-vv` you'll get DEBUG-level log messages printing out the name of each file as we start to check it, and you can set TY_MAX_PARALLELISM=1 in your env to make it very clear which file is causing the hang. That's how we debug these kinds of issues when they're reported to us.)
Yes, we love TypeForm! We plan to support it as soon as the PEP for it lands. Under the covers, we already support much of what's needed, and use it for some of our special-cased functions like `ty_extensions.is_equivalent_to` [1,2]. TypeForm proper has been lower on the priority list mostly because we have a large enough backlog as it is, and that lets us wait to make sure there aren't any last-minute changes to the syntax.
Stepping away from Forth in particular, one of the benefits of a stack-based / concatenative language is that it's easy to implement on constrained hardware. uxn [1] is a great example of that.
And shameless self-promotion, if you're interested in how these kinds of languages compare with more traditional named-based languages, with more theoretical constructs like the lambda calculus and combinatory logic, and with gadgets like a PyBadge — well you're in luck! I gave a talk about exactly that at the final Strange Loop [2].
pyx doesn't compete with PyPI; it's a private registry that companies can use e.g. to host internal-only packages, or to provide curated views of things like PyPI for compliance reasons.
> making changes which seemingly require their client (uv) be used
That's an explicit non-goal: "You won't need to use pyx to use uv, and you won't need to use uv to use pyx."
The Open Firmware bootloader also used a Forth as its command-line interface. That was used on PowerPC Macs before Apple switched over to Intel. (So, you know, two processor architectures ago.)
A common theme is that Forth-likes are very easy to implement on constrained hardware. I have a Strange Loop talk a couple of years ago where I go into this at the end, calling out uxn from the Hundred Rabbits folks. You might consider that more "hobbyist" than "production", but people are deriving real joy making apps and games in that ecosystem.
Well ours is not yet implemented, so it's too early to say whether they're compatible. :-)
But less snarkily, we do talk to them often (and the authors of other tools like mypy and pyright) to make sure we aren't introducing gross incompatibilities between the different type checkers. When there are inconsistencies, we want to make sure they are mindful rather than accidental; for good reasons; spec-compliant; and well documented.
The current plan is that they will remain separate tools, but will work together nicely if you are using both. For instance, we want to add type-aware and multi-file lints to ruff at some point down the line.
I don't know that I'd want the scripting language to be compiled, for reasons that are outside the scope of this reply. So removing that constraint, the coolest thing I've seen in this space recently is kyren's Piccolo:
ty is definitely not ready to be a pyright replacement yet. But it is usable as an LSP for simple things like go to definition, and deeper LSP features are on the roadmap for the eventual beta and GA releases.