> Are those results wrong?

I don't know. Some packages just don't work with type checkers, e.g. Django.

Is it not that he used the "--suppress-errors" flag yet it did not ignore the errors?

Maybe it's working but it's not useful.

I think the point here is that for something like Python the default behaviour should be an assumed return type of `Any` rather than throwing an error. Maybe that is the case and the GP had configured it otherwise.

At least the alpha milestone is May 12, but I don't think they've publically committed to anything.

In particular for me it would be great to have a better typechecker than Pyright available for Zed (basically why the editor is a nonstarter right now).

Is this standard promotion driven development? Or do the people who are trying to open source these products end up being blocked?

Sapling is actively developed, not "dead after 3 months": https://github.com/facebook/sapling/commits/main/

Have not tried building Buck2 (no personal use for it), but its also actively developed: https://github.com/facebook/buck2/commits/main/

We totally get why you might be skeptical and even address this in our FAQ: https://pyrefly.org/en/docs/pyrefly-faq/#how-do-i-know-this-...

We know we can't just ask for trust upfront. Instead, we want to earn it by showing up consistently and following through on our commitments. So, take us for a spin and see how we do over time. We're excited to prove ourselves!

It's slow as hell. And every version bump comes with a bunch of new warnings/errors by default that is quite disruptive if you want to keep it quiet. But mostly that it is annoyingly slow.

It’s dog slow. I realize we are talking about a python checker written in typescript, so two relatively slow languages combined, but still.

The dependency on node makes it a PITA to set up in non-vs code environments as well.

pyright doesn't do well with inspecting inherited types, at least in our experience. Falls far behind JetBrain's type checker in Pycharm. (This is one reason why pycharm >> zed.)

It has warnings that steer you away from idiomatic Python towards less idiomatic Python.

Idiomatic Python favours EAFP (Easier to Ask Forgiveness than Permission) over LBYL (Look Before You Leap), so you might write something like this when using TypedDicts:

    try:
        foo = bar["baz"]["qux"]
        ...
    except KeyError:
        ...

Pyright warns you about this and pushes you to write this:

    if "baz" in bar and "qux" in bar["baz"]:
        foo = bar["baz"]["qux"]
        ...
    else:
        ...

They identified this as a bug and fixed it, then changed course and decided to reinstate the behaviour. So if you want to write idiomatic Python, you need to disable typechecking TypedDicts.

— https://github.com/microsoft/pyright/issues/1739

Now if this were a linter then I would understand. But a type checker should not be opinionated to the point of pushing people not to use idiomatic Python.

    if bar.get("baz", {}).get("qux") is not None:
    ...

When I last compared it to mypy a few months ago adding typechecking to an old project that had types but I had for some reason never actually run a typechecker on it:

* Was overwhelmingly slower than mypy

* Had a few hundred more false positives. I gather from reading their philosophy afterward that this was on purpose. Rigid dogma > doing the right thing in the circumstance in their opinion.

* Did not find any actual bugs, whereas mypy identified 3 errors that lead to fixing real issues AND had fewer false positives, due to its better understanding of python code.

* Comically overweight with its typescript dependency.

My first impression of it was of a very low quality, over engineered project prioritizing noise over signal. Looking forward to trying out the astral typechecker as well.