Ty: A fast Python type checker and language server
198 comments
·May 7, 2025zanie
davedx
What might, possibly, redeem Python in my eyes as a potential language for making production applications (something that today, it is most certainly not) would be if the type checker worked across the broader ecosystem of common Python packages.
For example, as my recent struggles showed, SQLAlchemy breaks `pyright` in all kinds of ways. Compared with how other 'dynamic' ORMs like Prisma interact with types, it's just a disaster and makes type checking applications that use it almost pointless.
How does Ty play with SQLAlchemy?
jakewins
My experience is this is nearly impossible, the solution is new packages written after typing was introduced.
I don’t know about SQLAlchemy, but for libraries like pandas I just don’t see how it can be done, and so people are actively replacing them with modern typed alternatives
davedx
Ha. I just finished a huge rewrite at work from sync SQLAlchemy to async SQLAlchemy, because the async version uses a totally different API (core queries) to sync. So this implies if I want type checking I need to use a different ORM and start again?
I love how Python makes me so much faster due to its dynamic nature! Move fast, break things!
wpeterw
You mean Python is not a language for production applications ?
pjmlp
Only when performance doesn't matter, then it becomes a DSL for C and C++ libraries.
pjmlp
For me, until it gets a production quality JIT, or PyPy and GraalPY get more community love, it remains a scripting language for learning on how to program, automating OS and applications tasks.
ukblewis
Have you tried SQLModel?
BewareTheYiga
For pre-alpha software it's working fantastic for my project. I thought I type annotated it well, but Ty had quite a lot of feedback for me. Great job and I can't wait until this is released.
IshKebab
Had you checked it with Pyright previously?
BewareTheYiga
I've only used Pylance standard type checking in vscode. I have not used pyright as a stand alone package.
12_throw_away
If you can say - are there any thoughts about implementing plugins / extension capabilities to keep type checking working even with libraries that aren't otherwise typecheckable?
(where "not otherwise typecheckable" means types that can't be expressed with stubs - e.g., Django, dataclasses pre-PEP-681, pytest fixtures, etc.)
dcreager
At least for the moment, we aren't planning on a plugin architecture. We do recognize that there are some popular libraries and code patterns that aren't easily (or at all) typeable with the current state of the typing spec. We feel it would be more useful to help drive changes to the typing spec where we can, so that other type checkers can also benefit; and/or implement workarounds for the most popular libraries directly in ty, so that a library author doesn't have to rely on their downstream consumers installing a particular set of plugins to get good type-checker results.
(It's also more difficult to support plugins effectively in a type checker like ty, than in a linter like ruff, since any non-trivial use case would likely require deep changes to how we represent types and how we implement type inference. That's not something that lends itself to a couple of simple hook extension points.)
tyrion
Helping improve the spec and all is great, but being 100% honest, as a user, I would rather have a type checker I can bend to my needs. As you said, some code patterns in a dynamic language like Python are difficult, or even impossible, to type-check without custom code. Type checkers are becoming more popular than ever, and this implicitly means that these code patterns are are going to be discouraged. On one hand, I believe the dynamism of Python is core to the language. On the other, I would never want to write any collaborative piece of software without a type checker anymore. Therefore, to get the benefits of a type checker, I am occasionally forced to write worse code just to please it.
Considering how fast uv and ruff took off, I am sure you are aware of the impact your project could have. I understand that supporting plugins is hard. However, if you are considering adding support for some popular libraries, IMHO, it would be really beneficial for the community if you could evaluate the feasibility of implementing things in a somewhat generic way, which could be then maybe leveraged by third-party authors.
In any case, thanks for all the amazing work.
danlamanna
I also asked this question here: https://github.com/astral-sh/ruff/discussions/15149#discussi....
collinmanderson
https://pypi.org/project/django-types/ is compatible with pyright without plugins, so it should theoretically work with ty. It might not check as much as mypy though especially with values() querysets.
digdugdirk
Cool! Out of curiosity, what's the bedrock that's used to determine what the fundamental python AST objects are? I'm wondering what the "single source of truth" is, if you will.
Is this all based off a spec that python provides? If so, what does that look like?
Or do you "recode" the python language in rust, then use rust features to parse the python files?
Regardless of how it's done - This is a really fascinating project, and I'm really glad you guys are doing it!
dcreager
There is a formal grammar defined in the CPython repo, implemented in a language called ASDL:
https://github.com/python/cpython/blob/main/Parser/Python.as...
ty uses the same AST and parser as ruff. We don't use the ASDL grammar directly, because we store a few syntax nodes differently internally than how they're represented upstream. Our parser is hand-written in Rust. At first, our AST was also entirely hand-written, though we're moving in the direction of auto-generating more of it from a declarative grammar.
https://github.com/astral-sh/ruff/issues/15655
https://github.com/astral-sh/ruff/tree/main/crates/ruff_pyth...
https://github.com/astral-sh/ruff/blob/main/crates/ruff_pyth...
zanie
ditto! but we gave impressively non-overlapping answers
zanie
As in, how are we parsing the Python code into an AST?
CPython uses a generated parser. The grammar is defined in https://github.com/python/cpython/blob/main/Grammar/python.g... which is used to generate the specification at https://docs.python.org/3/reference/grammar.html#full-gramma...
We use a hand-written parser, in Rust, based on the specification. We've written that previously at https://astral.sh/blog/ruff-v0.4.0#a-hand-written-parser
theLiminator
Curious if this means it'll be released as a separate binary than ruff? I personally feel like having it within ruff is much nicer for ensuring that we have a consistent set of dependencies that play nicely with each other. Though I guess because a type checker doesn't mutate the files maybe that's not a real concern (vs formatting/linting with --fix).
zanie
It'll be separate (at least to start) — we want to be able to iterate on it rapidly. Long-term, a consistent toolchain is definitely important and something we're thinking about.
skwashd
+1 for (eventually) baking it ty into ruff. In my mind static type checking is a form of linting.
For years I pushed black for formatting code. Once formatting was baked into ruff I ditched black. Having fewer dependencies to track and update simplifies my life and shortens my dependabot queue.
ZiiS
Pointlessmy anal; but 0.0.0a6 is very strongly indicative of the sixth alpha release. Pre-alpha are much better as .dev releases.
usr9012809
> Pre-alpha are much better as .dev releases.
No, they are correctly using semantic versioning to indicate pre-alpha releases. https://github.com/astral-sh/ty/releases https://semver.org/
kstrauser
Python doesn’t use plain semver: https://peps.python.org/pep-0440/
ngoldbaum
I gave away the “ty” project name on pypi to Astral a week or so ago. I wanted to use it for a joke a few years ago but this is a much better use for a two letter project name. They agreed to make a donation to the PSF to demonstrate their gratefulness.
_carljm
Yes, thank you for your graciousness and generosity, very much appreciated.
Celeo
I love this outcome; kudos to you and Astral both!
swyx
thanks for not charging obnoxious amounts for package names!
null
smitty1e
ty--thank you
aleksanb
The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.
The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods.
I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".
mjr00
> The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.
Or in this case, writing it in Rust...
mypy is written in Python. People have forgotten that Python is really, really slow for CPU-intensive operations. Python's performance may not matter when you're writing web service code and the bottlenecks are database I/O and network calls, but for a tool that's loading up files, parsing into an AST, etc, it's no surprise that Rust/C/even Go would be an order of magnitude or two faster than Python.
uv and ruff have been fantastic for me. ty is definitely not production ready (I see several bizarre issues on a test codebase, such as claiming `datetime.UTC` doesn't exist) but I trust that Astral will match the "crazy reality" of real Python (which I agree, is very crazy).
dcreager
> such as claiming `datetime.UTC` doesn't exist)
This is a known issue — we're currently defaulting to a conservative Python version, and `datetime.UTC` really doesn't exist until Python 3.11!
https://docs.python.org/3/library/datetime.html#datetime.UTC
We will probably change the default to "most recent supported Python version", but as mentioned elsewhere, this is very early and we're still working out these kinds of kinks!
zo1
You should be doing this dynamically based on the version of python you are running against, so that you don't have to hardcode or make such "conservative" choices by hand.
_carljm
(ty developer here)
Currently we default to our oldest supported Python version, in which `datetime.UTC` really doesn't exist! Use `--python-version 3.12` on the CLI, or add a `ty.toml` with e.g.
``` [environment] python-version = "3.12" ```
And we'll find `datetime.UTC`.
We've discussed that this is probably the wrong default, and plan to change it.
miki123211
I realize this might be hard from a technical / architecture standpoint, but it would be great if "does not exist" and "does not exist in this version of Python" were two different errors.
If I saw something like "datetime.UTC doesn't exist", I'd immediately think "wait, was that datetime.utc", not "ooh it got added in 3.11, I need to change my Python version"
mjr00
aha makes sense! Yeah it'd be nice if you could divine the intended python version from the uv configuration/`.python-version`. Thanks for all your hard work, looking forward to the full release!
miki123211
Python is slow for some CPU-intensive operations.
There are some extremely CPU-intensive low-level operations that you can easily write in C and expose as a Python API, like what Numpy and Pandas do. You can then write really efficient algorithms in pure Python. As long as those low-level operations are fast, those Python-only algorithms will also be fast.
I don't think this is necessarily "cheating" or "just calling disguised C functions." As an example, you can write an efficient linear regression algorithm with Numpy, even though there's nothing in Numpy that supports linear regression specifically, it's just one of the ways a Python programmer can arrange Numpy's low-level primitives. If you invent some new numerical algorithm to solve some esoteric problem in chemistry, you may be able to implement it efficiently in Python too, even if you're literally the first person ever writing it in any language.
The actual problem is that it's hard for people to get an intuition of which Python operations can be made fast and which can't, AST and file manipulation are sadly in the latter group.
null
davidfstr
mypy is compiled using mypyc. It does not run as Python code.
mzl
The semantics of Python makes it problematic to run at speed, it is not just about interpreted vs compiled code. Give the high levels of dynamic behaviors that are allowed, a Jit (like pypy) has a higher chance of getting decent performance if the code has an underlying behavior that can be extracted.
johnfn
In defense of mypy et al, Typescript had some of the greatest minds of our generation working for a decade+ on properly typing every insane form found in every random Javascript file. Microsoft has funded a team of great developers to hammer away at every obscure edge case imaginable. No other python checker can compare to the resources that TS had.
dathinab
It's even worse (for python).
TS might transpile to JS and can always be split into a js and type annotation file but is it's own language developed in tandem with the type check based on a holistisch approach to find how to type check then and then put it into the syntax and type checker.
Thats not true for python at all.
Python types where added as annotations to the language many years ago, but not in a holistic approach but in simplistic approach only adding some fundamental support and then extended bit by bit over the years (and not always consistently).
Furthermore this annotations are not limited to type checking which can confuse a type checker (through Annotated helps a lot, but is also verbose, wonder how long until there is a "Annotated" short syntax e.g. by impl @ on type or similar).
Basically what the type annotation feature was initially intended to be and what it is now differ quite a bit (dump example `list` vs. `List`, `Annotated` etc.).
This is made worse that a bunch of "magic" is deeply rooted in python, e.g. sub-classing `Enum`. Sure you have that in JS too, and it also doesn't work that well in TS (if you don't add annotation on the dynamically produced type).
Lastly TS is structurally typed, which allows handling a bunch of dynamic typing edge cases, while Python is, well, in-between. Duck-typing is (simplified) structural typing but `isinstance` is a common thing in Python and is nominal typing...
So yeah it's a mess in python and to make it worse there bunch of annoyances related to ambiguity or to many ways how to do a thing (e.g. re-exports+private modules, you can do that common coding pattern, but it sucks badly).
spooky_action
It's not perfect, but runtime_checkable is a thing https://docs.python.org/3/library/typing.html#typing.runtime...
It doesn't actually preserve typing on the protocol's methods though
surfingdino
What annoys me is that every programmers who wish their favourite language / feature was as popular as Python and they choose to implement it in Python to make Python "better". Python was created as a dynamically typed language. If you want a language with type checking, there are plenty of others available.
Rust devs in particular are on a bend to replace all other languages by stealth, which is both obviously visible and annoying, because they ignore what they don't know about the ecosystem they choose to target. As cool as some of the tools written for Python in Rust are (ruff, uv) they are not a replacement for Python. They don't even solve some annoying problems that we have workarounds for. Sometimes they create new ones. Case in point is uv, which offers custom Docker images. Hello? A package manager is not supposed to determine the base Docker image or Python version for the project. It's a tool, not even an essential one since we have others, so know your place. As much as I appreciate some of the performance gains I do not appreciate the false narratives spread by some Rust devs about the end of Python/JavaScript/Golang based on the fact that Rust allowed them to introduce faster build tools into other programming languages' build chains. Rust community is quickly evolving into the friends you are embarrassed to have, a bit like any JVM-based language that suddenly has a bunch of Enterprise Java guys showing up to a Kotlin party and telling everyone "we can be like Python too...".
smithkl42
And in the process, they ended up creating an extremely powerful type system that ~nobody outside of that original team can (fully) understand.
dathinab
IMHO they created type annotations, not a type system
and how you use the type annotations to indicate a type system is inconsistent and incomplete (e.g. NoneType vs. None for inconsistency and a lot of mess related to mataclasses (e.g. Enum) and supporting type annotations for them for incomplete)
the fact that even today something as fundamental as enums have issues with type checking _which are not just type checker incompetence_ is I think a good way to highlight what mess it is
or that `Annotated[]` was only added in 3.9 and has a ton of visual overhead even through its essential for a lot of clean definitions in modern python code (where for backwards compatibility there is often some other way, which can be de-facto wrongly typed but shouldn't be type linted, have fun type checkers).
bvrmn
It's not mypy issue. Comparing to TS python typehints (spec wise) are a joke. It's started as bolted on adhoc solution and evolved quite chaotically. For example [1]. TS doesn't require a special decorator (sic!) to make your custom classes to be picked up by type checkers.
Or how make a wrapper function with args and kwargs to pass through?
[1]: https://docs.python.org/3/library/typing.html#typing.datacla...
TheTaytay
Even Typescript is rewriting their compiler in Go. I think that the bottleneck is _actually_ the language sometimes.
(And uv and ruff have basically proved that at this point)
dathinab
through algorithmic improvements can also go a long way and if you are one of the first type checker which have to figure out the mess the python type annotation system is you will vast a lot of time on figuring that out instead of refactoring it's architecture to allow for algorithmic improvements
which brings us to another python issue, python is quite bad at such huge refactoring even with type checkers
but yeah python is by far the slowest widely used language, and for some use cases you can side step it by placing most hot code in C++/Rust extension modules, (or don't care because you are much much more network latency bound) but a type checker probably doesn't belong into that category
davedx
Can mypy type check SQLAlchemy somehow? That's what caused me to give up on Python type checking recently
lukaslalinsky
SQLAlchemy 2.x has direct support for mypy, it works out of the box, no longer needing mypy plugins. Many things in SQLAlchemy as are still dynamic and can't be type checked, but the native support works great where it can.
amelius
> I wish more python tooling
And not directly related, but I wish more python modules did proper checks with Valgrind before shipping.
lyu07282
The CPython API is such a dumpster fire, even writing very simple modules the reference counting is very difficult to do correctly. The majority of python modules written in C are probably leaking memory somewhere but nobody knows.
HideousKojima
>The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.
Nah, that's just part of the parade of excuses that comes out any time existing software solutions get smoked by a newcomer in performance, or when existing software gets more slow and bloated.
Here's one of many examples:
https://m.youtube.com/watch?v=GC-0tCy4P1U&pp=0gcJCdgAo7VqN5t...
Redoubts
Sure, but so far this has been a true criticism of every python type checker that isnt mypy that is production ready today
dathinab
the thing is most (all) of the type checkers including e.g. mypy _do not_ support most crazy python ...
not because they don't want to or because it's to slow
but because it's not really viable without fully executing module loading in a sandbox, which might seem viable until you realize that you still need to type check `__main__` modules etc. and that its a common trend in python to do configs by loading python modules and grabbing the module locals as keys of the config or loading some things might actually idk. initialize a GPU driver :sob: So it's kinda 100% guaranteed not possible to do fully correct type checking for all project :smh:
But also python is one of the slowest popular languages (and with a large margin to any not also "one of slowest" languages). Only by moving hot code into C++/Rust is it fast, which often is good enough, but a type checker is exactly this kind of software where this approach stops working.
tmvphil
Just compared the time to check on a fairly large project:
- mypy (warm cache) 18s
- ty: 0.5s (and found 3500 errors)
They've done it again.
_carljm
(ty developer here)
This is an early preview of a pre-alpha tool, so I would expect a good chunk of those 3500 errors to be wrong at at this point :) Bug reports welcome!
joshdavham
Any rough estimates of how much faster you expect ty to be compared to mypy? I'd be super curious to know!
I was also one of those people who, when first trying Ruff, assumed that it didn't work the first time I ran it because of how fast it executed!
_carljm
We're looking forward to hearing what your experience is! There's a certain amount of roughly-constant overhead (e.g. reading all the files), so generally ty will look relatively faster the larger the project is. For very large projects we've seen up to 50-60x faster or more. We haven't really put a lot of work into targeted optimization yet, so we aim for it to get faster in the future.
It will certainly be slower than Ruff, just because multi-file type analysis more complex and less embarrassingly parallel than single-file linting.
mil22
Great, but how does it compare to Pyright on the utility / performance curve? Pyright is mature and already very fast.
mil22
I tested it side-by-side on my ~100Kloc codebase.
Ty: 2.5 seconds, 1599 diagnostics, almost all of which are false positives
Pyright: 13.6 seconds, 10 errors, all of which are actually real errors
There's plenty of potential here, but Ty's type inference is just not as sophisticated as Pyright's at this time. That's not surprising given it hasn't even been released yet.
Whether Ty will still perform so much faster once all of Pyright's type inference abilities have been matched or implemented - well, that remains to be seen.
Pyright runs on Node, so I would expect it to be a little slower than Ty, but perhaps not by very much, since modern JS engines are already quite fast and perform within a factor of ~2-3x of Rust. That said, I'm rooting for Ty here, since even a 2-3x performance boost would be useful.
the_duke
Compilation / type checking depends on a lot of trees of typed data, and operating on those tree nodes. That's something where a statically typed language with custom data structures that allows for optimised representations makes a big difference, and where a lot of the fancy optimisations in v8 don't work so well.
There is a reason Typescript moved to a typed language.
rtpg
I don't get why so many people go to bat for pyright, my experience with it has been pretty miserable. Open enough instances of it and you're in OOM city. It works, but often gets confused... and of course the absolute audacity of MSFT to say "let's go over to pyright, and by the way we're going to carve up some stuff and put it into pylance instead", meaning that it's totally not within the actual spirit of open source.
I would like to just not use it, but the existence of pyright as a _barely_ functional alternative really sucks the air out of other attempts' continued existence. Real "extend/extinguish" behavior from MSFT.
lemontheme
If you haven’t checked it out already, basedpyright is pyright with all the arbitrarily carved out functionality put back in – plus some extra features that you may or may not find useful depending on how strict you like your typing.
Can’t recommend it enough
bjourne
Pyright is only for type-checking and it lacks many features you'd expected from a modern LSP (I forgot which). Hence, it was forked and someone created basedpyright to fix it: https://github.com/DetachHead/basedpyright
dathinab
To extend on this:
In python it's pretty common to have LSP separate from type checking separate from linting (e.g. ruff+mypy+ide_specific_lsp).
Which to be fair sucks (as it limits what the LSP can do, can lead to confusing mismatches in error/no-error and on one recent project I had issues with the default LSP run by vscode starting to fall apart and failing to propose auto imports for some trivial things for part of the project....)
But it's the stack where pyright fits in.
nine_k
Pyright is good, but it's quite a memory hog. (Yes, I have plenty of RAM on my machine. No, it has other uses during development, too.)
0xFF0123
Pyright is incredibly slow in my experience, I've seen it take over a minute on complex codebases
insane_dreamer
in my experience pyright is unable to infer many inherited object types (compared to PyCharm's type inference)
lemontheme
PyCharm definitely excels on more ‘dynamic’ code but the number of times I’ve pulled in code written by colleagues using PyCharm only to get a rainbow of type errors from Pyright is too damn high.
The PyCharm checker seems to miss really, really obvious things, e.g. allowing a call site to expect a string while the function returns bytes or none.
Maybe my colleagues just have it configured wrong but there’s several of them and the config isn’t shared.
catlover76
[dead]
js2
I have no doubt that it will be faster than mypy, but:
> This project is still in development and is not ready for production use.
rybosome
> They’ve done it again.
Indeed they have. Similar improvement in performance on my side.
It is so fast that I thought it must have failed and not actually checked my whole project.
Handprint4469
If you have uv installed, you can test it without installing by running:
uvx ty checksimonw
Here's what I got against one of my larger open source projects:
cd /tmp
git clone https://github.com/simonw/sqlite-utils
cd sqlite-utils
uvx ty check
Adding "time uvx ty check" shows it took:
uvx ty check 0.18s user 0.07s system 228% cpu 0.109 totalalexmolas
how does it compare against mypy? is it much faster?
IshKebab
How does it compare against Pyright. Pyright is the gold standard of Python type checking currently. Mypy is slower and buggier.
simonw
In the same folder:
time uvx mypy .
uvx mypy . 0.46s user 0.09s system 74% cpu 0.740 total
wdroz
You can also install it "globally" for your user with:
uv tool install ty
ty checkheavyset_go
Can also do
uv tool run ty
scosman
Found 275 diagnostics
0.56s user 0.14s system 302% cpu 0.231 total
Damn that's fast. And zero issues in this project with pyright so curious that these are...
blibble
prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's
astral have now replaced the awful pip with the fantastic uv
various awful linters with with the fantastic ruff
and now hopefully replacing the terrible type checkers (e.g. mypy) with a good one!
I hope they have the pypi backend on their list too, my kingdom for Maven Central in python!
kokada
> prior to astral appearing, python's tooling has been beyond terrible, compared to say, Java's
I would concur with you if you said Go, Rust, Ruby, or even heck, PHP, but Java is probably the only language that I know that is in a situation even as bad as Python or even worse (at least for me definitely worse, because at least I understand Python tooling enough even when using it only for hobby projects, while I still don't understand Java tooling enough even after working professionally with JVM languages for 7+ years).
Java is the only language that I know except Python that has multiple project/package managers (Maven, Gradle, probably even more). It also has no concept of lock files in at least Maven/Gradle, and while resolution dependency in Maven/Gradle is supposed to be deterministic, from my experience it is anything but: just a few weeks ago we had a deployment that failed but worked locally/CI because of dependency resolution somehow pulled different versions of the same library.
Fighting dependency hell because different dependencies pull different version constraints is a pain (all Java/JVM projects that I ever worked had some manually pinned dependencies to either fix security issues or to fix broken dependency resolution), and don't even get me in the concept of Uber JARs (that we had to use in previous job because it was the only way to ensure that the dependency tree would be solved correctly; yes maybe it was by incompetence of the team that maintained our shared libraries, but the fact that we even got at that situation is unacceptable).
Oh, and also Gradle is "so fun": it is a DSL that has zero discovery (I had IntelliJ IDEA Ultimate and I could still not get it to auto-complete 60% of the time), so I would just blindly try to discover what where the inputs of the functions. The documentation didn't help because the DSL was so dynamic and every project would use it slightly different, so it was really difficult to discover a way to make it work for that specific project (the examples that I would find would be enough different from my current project that 90% of time it wouldn't work without changing something). Python at least has `pyproject.toml` nowadays, and the documentation from PyPA is good enough that you can understand what you want to do after reading it for 10 minutes.
screye
Even after all the praise, I'd say they're underrated.
Modular.ai raised $100 million to solve tangentially similar problems with python. Astral has already had a much larger impact, while providing better integration with less than 10% of that money.
swyx
disagree. modular has a different focus, to turn python into a systems language.
you could even say that astral and modular focus on two extreme ends of the developer experience spectrum - just making python tooling faster, vs making python-ish code faster.
screye
To be clear, I wasn't dunking on Modular. I meant it more as praise for what Astral has achieved. Lattner is a veteran and Mojo seems to be coming along at a good pace. Mojo is admittedly more of a Rust-competitor. Couldn't think of other contemporary "we are trying fix python's problems" companies. So went for the low hanging fruit.
Either way, Python's irritants are the 'stick' that motivates devs to try alternatives. Astral is patching python's problems at lightning speed. Soon, there may not be enough incentive left to migrate off python. I'm assuming Mojo's target customer is an application dev who uses python and not a seasoned system dev looking for a more aesthetic language.
fwiw, I hope Mojo succeeds.
sakesun
Credit should also go to Rye project by Armin Ronacher.
lemontheme
Yeah, iirc he was the first to go ‘what if we had cargo for python?’
danlamanna
> I hope they have the pypi backend on their list too
IIRC they have floated the idea of private registries as a commercial offering in the past.
zahlman
What issues do you have with the PyPI backend?
no_time
Awesome work. What is the business model for these astral tools? It’s a bit of a “waiting for the other shoe to drop” feeling after seeing the VC backing on the company page.
lemontheme
From what I’ve gathered (because I had similar concerns), the code is properly open source. In the very worst case, should there ever come a rug pull, it can be forked.
nickagliano
Interesting to see astral come out with this right around facebook’s release of “Pyrefly, a faster Python type checker written in Rust”.
Not making any sort of ethical statement, just interesting that rust keeps eating the python and JS tooling worlds.
masklinn
> Interesting to see astral come out with this right around facebook’s release
Astral announced they were building a typechecker back in January: https://x.com/charliermarsh/status/1884651482009477368
emptysea
Also interesting, pyrefly uses Ruff’s parser!
https://github.com/facebook/pyrefly/blob/a8626110da034f8e513...
tasn
Astral announced it last year I think, so it's been a long time coming.
ipsum2
Pyrefly is a rewrite of Pyre, a Python typechecker which has been around for 4-5 years. Pyre is the strictest type checker I've used, compared to mypy, but its kind of a pain to set up.
akdor1154
Yeah.. Have either of the ty / pyrefly teams reached out to the other? I feel like the community does not really need two fast python type checkers.
(However, vc-backed astral probably need control over theirs to keep monetization options open, and Facebook probably need control over theirs so it can be targeted at Facebook's internal cool-but-non-standard python habits... Sigh.
Why do we have nice things? Money. Why can't we have nice things? Also money.)
_carljm
Yes, we've talked; I know a number of the pyrefly devs well. Ty had already been months in development when pyrefly development started. We discussed collaboration, but they decided they needed to do their own thing in order to move quickly and ensure it would serve their needs, which is totally reasonable.
zem
language tooling is a sweet spot for rust, for sure.
rexledesma
Very excited to have a new fully featured Python language server working in both vscode and vscode forks (e.g. Windsurf, Cursor).
Pylance is borked on these forked distributions, so having a new solid alternative here that doesn't involve adopting yet another forked Pyright implementation (BasedPyright, Cursor Pyright, Windsurf Pyright, ...) sounds great to me.
maxloh
You should try basedpyright: https://docs.basedpyright.com/latest/
> basedpyright re-implements many features exclusive to pylance - microsoft's closed-source extension that can't be used outside of vscode.
rexledesma
I mentioned it in my initial comment. Ideally, I would like to use the same type checker/LSP for a language everywhere (any of my local editors, CI/CD).
This is especially important when working in a team setting.
It doesn't feel great to use a forked type checker/LSP that's not enforced in your org's CI/CD. And it also doesn't feel great to force the forked type checker onto the entire organization when only a subset of folks may be using a forked vscode editor.
krupan
Have these guys figured out how to make money yet?
dcreager
We're going to set up a lemonade stand in the main hall at PyCon next week
all2
This might actually be a decent business model. Sell hard goods to fund your habit of making excellent software tools.
digdugdirk
Fingers crossed this isn't a joke.
dcreager
Well, it is a joke...but that said, we're hosting a happy hour which is kinda similar!
never_inline
They might pivot to some enterprise value added services. Probably around SAST - think sonarqube.
joshdavham
I'm curious to see what Astral will cook up! I assume they'll probably eventually create some sort of paid devtool service.
With that being said, the worst case scenario is that they go caput, but that still leaves the python community with a set of incredible new rust-based tools. So definitely a net win for the python community either way!
__MatrixMan__
If they're making our lives better, perhaps the question is whether we've figured out how to pay them yet.
codr7
From my experience it's VERY rare for people to pay for anything unless they're forced, I do the same thing even though I'm very aware of the need for compensating creators.
Talk is cheap, and people talk a lot about supporting projects.
Maybe if we could make some kind of statistics over the number of projects that were abandoned because maintainers didn't feel like working and dealing with random people for free anymore. Make the consequences of freeloading visible somehow.
__MatrixMan__
That has been my experience as well. I consider it a bug. I'm not proposing that we all just try harder to be altruistic, but rather that we craft some institution for rewarding people who have solved problems for many without encumbering those solutions with a monetization scheme.
Make like, a week long "holiday" where you either verify that your company has made an adequate donation to the OSS maintainers that make their products possible, or we all just go on strike for that week. Or... something. I'm sure somebody has a better idea than mine, lets get creative.
pamelafox
I am literally checking HackerNews while I wait for mypy to finish running, so I am excited to hear a faster type checker is on the way! Hope the error messages are also helpful.
null
:wave:
Looks like you found the not-so-secret repository we're using to prepare for a broader announcement :)
Please be aware this is pre-alpha software. The current version is 0.0.0a6 and the releases so far are all in service of validating our release process. We're excited to get this in people's hands, but want to set the expectation that we still have a lot of work left to do before this is production ready.
Stay tuned for more for news in the near future!
(... I work at Astral)