https://pypistats.org/packages/uv

Such an outcome would make me wonder regarding the wisdom of "It is better to have love and lost than to have never loved at all."

Note that uv is fast because — yes, Rust, but also because it doesn’t have to handle a lot of legacy that pip does[1], and some smart language independent design choices.

If uv became unavailable, it’d suck but the world would move on.

[1] https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Like, the whole point of open source is that this thread is not a thing. The whole point is "if this software is taken on by a malevolent dictator for life, we'll just fork it and keep going with our own thing." Or like if I'm evaluating whether to open-source stuff at a startup, the question is "if this startup fails to get funding and we have to close up shop, do I want the team to still have access to these tools at my next gig?" -- there are other reasons it might be in the company's interests, like getting free feature development or hiring better devs, but that's the main reason it'd be in the employees' best interests to want to contribute to an open-source legacy rather than keep everything proprietary.

Projects - including forks - fail all the time because the leadership/product direction on a project goes missing despite the tech still being viable, which is why people are concerned about these people being locked up inside OpenAI. Successfully forking is much easier said than done.

I had a sketched out design for a correct package manager in 2018 but when I talked to people about it I couldn't get any interest in it. I think the brilliant idea that uv had that I missed was that it can't be written in Python because if is written in Python developers are going to corrupt its environment sooner or later and you lose your correctness.

I think that now that people are used to uv it won't be that hard to develop a competitor and get people to switch.

Ruff isn’t stable yet either and has evolved into the de facto standard for new projects. It has more than double the amount of rules than Pylint does. Also downloaded more than 3 times as often as Pylint in the past month.

Pylint has some advantages, sure, but Ruffs adoption speaks for itself. Pylint is 25 years old. You’d hope they do some things better.

Saying that uv is their only winner is a hilarious take.

na this news is good enough reason to move from Ruff back to black and stay the course, I won't use anything else from Astral. I will use uv but only until pip 2/++ gets its shit together and catches up and hopefully then as a community we should jump back on board and keep using pip even if it's not as good, it's free in the freedom sense.

> I would stare longingly into the void, wondering if I can ever work another python project after having experienced uv, ruff, and ty.

You think you're disagreeing with me, but you're agreeing. To wit: The original post is silly, because ty is beta quality and Ruff isn't stable yet either. Your words.

These are just tools, Pylint included. Use them, don't use then, make them your whole personality to the point that you feel compelled to defend them when someone on the Internet points out their flaws. Whatever churns your butter.

Then import that tool and and check if __name__ == "__main__"

Or are you asking why I haven't had success? Mostly because the people I work with are dead set that Python is perfect for everything. I had one guy argue it should be used for embedded work

The domain I work in is basically perfect for Go, so I've been pushing for that.

I had the problem basically understood in 2018 and I am still pissed that everybody wanted to keep taking their chances with pip just like they like to gamble with agent coders today.

Now that people know a decent package manager is possible in Python I think there is going to be no problem getting people to maintain one.

And that's a big part of what's so frustrating about Python generally: it seems to be a language used by lots of people who've never used anything else and have an attitude like "why would I ever try anything else"?

Python has a culture where nominal values of user-friendliness, pragmatism, and simplicity often turn into plain old philistinism.

How do you think the magic of open source resolves this issue? Think about this for it to make some sense

> I would simply fork

The only simple part here is pressing the "fork" button, which only gives you exactly the same code that already exists, without user awareness or distribution

as to how the magic of open source resolves the time and money issue, it literally gives you the building blocks you need to not have to invent everything from scratch. how is that not significant?

And I never said about the relative ease, you've moved the goalpost there yourself. $1m required to maintain is much less than $10m required to create, yet when you don't have $1m it doesn't matter - you'll still fail, and reasons are the same as the reasons you couldn't build the original.

Blocks lying around does not a building make, so you haven't addressed that magic either.

I'm done pretending this is a "right tools for the right job" kind of thing, there's wrong people in the right job, and they only know python. If no one self-writes code anymore anyway, at least use a language that isn't a clusterfuck of bad design decisions, and has 1 trillion lines of code in the collective memory of people who don't know what a stack is.

I can get behind the idea that LLM's probably don't need a language designed for humans if humans arent writing it, but the rest of this is just daft. Pythons popularity isn't just pure luck, in fact its only been in recent years that the tooling has caught up to the point where its as easy to setup as it is to write, which should really tell you something if people persevered with it anyway.

I'm sorry your favourite language doesnt have the recognition it so rightfully deserves, but reducing python to just "stupid language for stupid people" is, well, stupid

Speaking as a grey beard myself, I think its safe to say that the grey beards among us will always deride those who didn't have to work as hard as they did.

https://peps.python.org/pep-0723/

* disclosure: We are a commercial client of astral.sh

Circa 2017 I was working on systems that were complex enough that pip couldn't build them and after I got to the bottom of it I knew it not my fault but it was the fault of pip.

I built a system which could build usable environments out of pre-built wheels and sketched out the design of a system that was roughly 'uv but written in Python' but saw two problems: (1) a Python dependent system can be destroyed by people messing with Python environments, like my experience is that my poetry gets trashed every six months or so and (2) there was just no awareness by the 'one tiny project on your machine that pips in four packages' people that there was a correctness problem at all and everybody else was blaming themselves for a problem and didn't have a clear understanding of what was wrong with pip or what a correct model for managing python dependencies is (short answer: see maven) or that a 100% correct model was even possible and that we'd have to always settle for a 97% model. The politics looked intractable so I gave up.

Now written in rust, uv evaded the bootstrap problem and it dealt with the adoption problem by targeting 'speed' as people would see the value in that even if they didn't see the value in 'correctness'. My system would have been faster than pip because it would have kept a cache, but uv is faster still.

I have used them all and UV is the only one that actually solves the problem.

It’s insane that people would suggest that Python can go back.

I always looked down on the Java ecosystem but if it turns out Maven had a better story all along and we all overlooked it, that's wild.

> The politics looked intractable so I gave up.

So yeah, this is your actual problem. (Don’t worry, I’m in the same camp here.)

Having a static binary makes distribution way simplier. There are a bunch of ways you could try to achive something like in python but it would be significantly larger.

Performance-wise writing it in python would have heavy startup overhead and wouldn't be able to get close to the same level of performance.

Obviously you could achive the same thing in many other languages, but rust ends up being a really good fit for making a small static binary for this workload of network heavy, IO-bound, async/threading friendly with the occasional bit of CPU heavy work.

you mean pdm?

Poetry having users isn’t the metric for success. pip having way less users is.

Poetry's CLI would often, for me, just fall over and crash. Crashing a lot is not a fundamental problem in the sense you can fix the bugs, but hey I'm not hitting uv crashes.

pipenv was even worse in terms of just hanging during package resolution. Tools that hang are not tools you want in a CI pipeline!

The end result: `uv run` I expect to work. `pipenv` or `poetry` calls I have to assume don't work, have to put retries into CI pipelines and things like that.

I think I have trauma from virtual environments...

But yes, in terms of user interface they are pretty similar. UV performance really does make the difference.

What exactly is the issue with this?

`uv run` a .py with inline script metadata has all the deps installed and your script running in a venv while poetry is still deciding to resolve...

I used to do backend development in superior languages, and sometimes do hobby frontend in superior languages, but my work is Python now. And it kind of has to be Python: we do machine learning, and I work with GDAL and PDAL and all these other weird libraries and everything has Python bindings! I search for "coherent point drift" and of course there's a Python library.

The superior languages I mentioned... perhaps they have like a library for JSON encoding and decoding. You need anything else? Great, now you're a library author and maintainer!

To make it good, you need to review and interate.

we may want to invent something akin to concise math notion, but not so much, in between pseudo-code and math.

(I'm not doing this to be a dick, I genuinely want to know what the use case is)

You can run a script with a one liner and it will automatically get you the same python and venv and everything as whoever distributed the python code, in milliseconds if the packages are already cached on your local computer.

Very easy to get going without even knowing what a venv or pypi or anything is.

If you are already an expert you get “faster simpler tooling” and if you are a complete beginner it’s “easy peasy lemon squeezy”.

Things got bearable with virtualenv/virtualenv wrappers, but it was never what I would call great. Pip was always painful, and slow. I never looked forward to using them - and every time I worked on a new system - the amount of finaggling I had to do to avoid problems, and the amount of time I spent supporting other people who had problems was significant.

The day I first used uv (about is as memorable to me as the the day I first started using python (roughly 2004) - everything changed.

I've used uv pretty much every single day since then and the joy has never left. Every operation is twitch fast. There has never once been any issues. Combined with direnv - I can create projects/venvs on the fly so quickly I don't even bother using it's various affordances to run projects without a venv.

To put it succinctly - uv gives me two things.

One - zero messing around with virtualenvwrappers and friends. For whatever reason, I've never once run into an error like "virtualenvwrapper.sh: There was a problem running the initialization hooks."

Two - fast. It may be the fastest software I've ever used. Everything is instant - so you never experience any type of cognitive distraction when creating a python project and diving into anything - you think it - and it's done. I genuinely look forward to uv pip install - even when it's not already in cache - the parallel download is epically fast - always a joy.

But - neither the speed nor constant issues with pip/virtualenvwrappers are really a function of the OS/File System.

A frequent theme in this thread (probably most clearly described in https://news.ycombinator.com/item?id=47444936) is that relying on your Python Environment to manager your Python Environment - always ends up in pain. Poetry had this issue as well.

One of the key architectural decisions of Astral was to write the Python Environment Management tooling in rust - so that it could never footgun itself.

It also benefited from very enlightened engineering decisions described here: https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

it just works. i'm not sure how else to describe it other than less faffing about. it just does the right thing, every time. there's a tiny learning curve (mostly unlearning bad or redundant habits), but once you know how to wield it, it's a one stop shop.

and as mentioned, it's crazy fast.

You should really qualify that statement, it implies that the Python ecosystem is bearable.

See the point ?

...and then I’ve read the rest of your comment. Please do go read the HN guidelines.

Or, more relevant to this conversion: If they closed source tomorrow, the community could fork the current version.

This is not the point of uv or any good package manager. The point is what prevents Python to suck. For a long time package management had been horrible in Python compared what you could see in other languages.

Not disputing that it's a great and widely used tool, BTW.

() Sure, they were on the shoulders of giants

- https://pypistats.org/packages/poetry - https://pypistats.org/packages/uv

In the 2024 Python developer survey, 18% of the ecosystem used Poetry. When I opened this manifold question[0], I'm pretty sure uv was about half of Poetry downloads.

Estimating from these numbers, probably about 30% of the ecosystem is using `uv` now. We'll get better numbers when the 2025 Python developer survey is published.

Also see this: https://biggo.com/news/202510140723_uv-overtakes-pip-in-ci-u...

[0]: https://manifold.markets/JeremiahEngland/will-uv-surpass-poe...

Perhaps it never grabbed me as much because I've been running basically everything in Docker for years now, which takes care of Python versioning issues and caches the dependency install steps, so they only take a long time if they've changed. I also like containers for all of the other project setup and environment scaffolding stuff they roll up, e.g. having a consistently working GDAL environment available instantly for a project I haven't worked on in a long time.

Second, you can use uv to build and install to a separate venv in a Docker container and then, thanks to the wonders of multistage Docker builds, copy that venv to a new container and have a fully working minimal image in no time, with almost no effort.

https://github.com/direnv/direnv/wiki/Python#uv

  $ type uvi uvl uvv
  uvi is a function
  uvi ()
  {
      uv pip install $@
  }
  uvl is a function
  uvl ()
  {
      uv pip list
  }
  uvv is a function
  uvv ()
  {
      uv venv;
      cat > .envrc <<EOF
  source .venv/bin/activate
  EOF

      direnv allow
  }

If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?

Mostly no, sometimes I give up and still use pip as a separate user.

> If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool

I haven't felt the need to use Go, the only Java software I use is in the OS repo. I don't want to use JS software for other reasons. This is one of the reasons why I don't like Rust rewrites. Python dependencies are very often in the OS repo. If there is anything else, I compile it from source and I curse when software doesn't use or adheres to the standard of the GNU build system.

Go and Rust, specifically, seem a bit odd to be allergic to. Their "package managers" are largely downloading sources into your code repository, not downloading/installing truly arbitrary stuff. How is that different from your (presumably "wget the file into my repo or include path") workflow for depending on a header-only C library from the internet which your OS doesn't repackage?

I understand if your resistance to those platforms is because of how much source code things download, but that still seems qualitatively different to me from "npm install can do god-knows-what to my workstation" or "pip install can install packages that shadow system-wide trusted ones".

And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

I favor stability and the stripping of unwanted features (e.g. telemetry) by my OS vendor over cutting edge software. If I really need that I install it into /usr/local, that it what this is for after all.

> And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

This is a reason to select the OS. Software shouldn't require exact versions, but should stick to stable interfaces.

The package manager I use, apt on Debian, does not package many Python development repos. They've got the big ones, e.g. requests, but not e.g. uuid6. And I wouldn't want it to - I like the limited Debian dev effort to be put towards the user experience and let the Python dev devs worry about packaging Python dev dependencies.

But the problem with only using the OS package manager is that you then lock yourself out of the entire ecosystem of node, python, rust packages that have never been migrated to whatever operating system you are using - which might be very significant.

How do you feel about Nix? It feels like this is a nice half-way measure between reliable/reproducible builds, but without all of the Free For all where you are downloading who-knows-what-from-where onto your OS?

Maybe there needs to be some nonprofit watchdog which helps identify those cases in their early stages and helps bootstrap open forks. I'd fund to a sort of open capture protection savings account if I believed it would help ensure continuity of support from the things I rely on.

(Source: I'm an Astral employee.)

That's a point of information, not a point of order.

If you've ever heard a line like "Mr Chair, I make a motion to X the Y" and then someone pipes up from a different part of the room "I second the motion!" and then someone important-looking says "A motion has been made and seconded, you may have the floor" - They're doing Robert's Rules.

And that's most of what I knew about Robert's Rules a minute ago, until I looked up the distinction GP was making above:

Point of Order: When a member thinks that the rules of the assembly are being violated, s/he can make a Point of Order (or "raise a question of order," as it is sometimes expressed), thereby calling upon the chair for a ruling and an enforcement of the regular rules.

Point of Information: a request for information on a specific question, either about process or about the content of a motion. A point of information does not give the speaker the privilege to provide information. If you have information for the body, raise your hand to be put on the speakers list.

from https://www.sheridan.edu/app/uploads/2018/11/Roberts-Rules-M...

Other types of interjection are point of personal privilege (eg seat is uncomfortable) and point of inquiry (clarification).

I came across them in the debating world. Point of information can be pretty effective if you're able to make a statement of fact contradicting something the other side declared.

See also: https://senate.oregonstate.edu/sites/senate.oregonstate.edu/...

[1]: https://astral.sh/blog/introducing-pyx

It's not perfect, but it is light-years better than what preceded it.

I jumped ship to it and have not looked back. (So have many of my clients).

It's so fast in fact that we just added `ty check` to our pre-commit hooks where MyPy previously had runtimes of 150+ seconds _and_ a mess of bugs around their caching.

I'm on the fence about cancelling my JetBrains subscription I've had for nearly 10 years now. I just don't use it much. Zed and Claude Code cover all my needs, the only thing I need is a serious DataGrip alternative, but I might just sit down with Claude and build one for myself.

It's a project I'm working on to build a database management product I've always wanted.

I spend way too much time obsessing over UX but hope people appreciate it :).

https://xkcd.com/2347/

It's not there yet, but it's getting there.

People need to be very careful about resisting. OpenAI wants to make everyone unemployed, works with the Pentagon, steals IP, and copyright whistleblowers end up getting killed under mysterious circumstances.

This is untrue. People frequently complained that they were VC funded and used it to justify mistrust.

Take this discussion, for example. Completely dominated by the topic.

https://news.ycombinator.com/item?id=44892209

1. For the record: the GPL is entirely dependent on copyright.

2. If AI "clean-room" re-implementations are allow to bypass copyright/licenses, the GPL won't protect you.

patents protect ideas, copyright protects artistic expressions of ideas

Isn't that the same for the obligations under BSD/MIT/Apache? The problem they're trying to address is a different one from the problem of AI copyright washing. It's fair to avoid introducing additional problems while debunking another point.

2. BigCo bus Company A

3a. usually here BigCo should continue to develop Project One as GPLv3, or stop working on it and the community would fork and it and continue working on it as GPLv3

3b. BigCo does a "clean-room" reimplementation of Project One and releases it under proprietary licence. Community can still fork the older version and work on it, but BigCo can continue to develop and sell their "original" version.

This is right up there with Meta lawyers claiming that when they torrent it's totally legal but when a single person torrents it's copyright infringement.

[0] https://legalblogs.wolterskluwer.com/copyright-blog/the-bart...

I'm careful to not rely too heavily on VC funded open source whenever I can avoid it.

All so they could just vacuum it all up and resell it with impunity.

Feel free to prove me wrong by pointing out this massive amount of advocacy from "mega-clouds" that changed people's minds.

The ads, the mailing list posts, social media comments. Anything at all you can trace to "mega-clouds" execs.

https://choosealicense.com/about/

> "GitHub wants to help developers choose an open source license for their source code."

This was built by GitHub Inc a very very long time ago.

So long ago, in fact, that it was five years before their acquisition by Microsoft.

https://opensource.stackexchange.com/questions/1150/is-my-co...

The ones pushing for permissive licenses are rather companies like Apple, Android (and to some extent other parts of Google), Microsoft, Oracle. They want to push their proprietary stuff and one way to do that in the face of open source competition is by proprietary extensions.

The FOSS community at large embraced permissive licenses and it had nothing to do with the interests of big corporations.

And, sure, djb wasn't actually likely to sue you if you went ahead and distributed modified versions of his software... but no-one else was willing to take that risk, and it ended up killing qmail, djbdns, etc stone dead. His work ended up going to waste as a result.

Agreed with the rest, though. I relied heavily on qmail for about a decade, and learned a lot from the experience, even if it was a little terrifying on occasion!

I mean philosophically and morally, sure, one can take that position ... but copyright law does not work like that, at least not for anything published in the US after 1989 [1].

[1] https://www.copyright.gov/circs/circ03.pdf

Not everybody is dictated by corporate attorneys; I don’t think this is an accurate portrayal.

and that seems like a strange choice…

Could you say more?

Preferring GPL licensed software means that you're immune to a sudden cut off of access so it's always advisable - but it's really important to stay on top of dependencies and be willing to pay the cost if support is withdrawn. So GPL helps but it isn't a full salve.

My experience is that I have personally committed code from Cinder (CPython fork internally from Meta) back into CPython and it was determined that features didn't align with CPython and this isn't some kind of dig between each project at all. Also, at a large mega corporation nearly all groups that use critical software with high complexity they all will have internal forks. I'm not sure what exactly what UV will have added on internally but instead of versions I think that you will have patch collections that might be beneficial to OpenAI but not necessarily for everyone. I hope that OpenAI will interact with the rest of the community and those internal patches can be ported into the overall system if it provides benefit.

The issue that I see is that Nvidia etc. are incentivised to perpetuate that so the open source community gets the table scraps of distills, fine-tunes etc.

The tradeoff with these unified LPDDR machines is compute and memory throughput. You'll have to live with the ~50 token/sec rate, and compact your prefix aggressively. That said, I'd take the effortless local model capability over outright speed any day.

Hope the popularity of these machines could prompt future models to offer perfect size fits: 80 GiB quantized on 128 GiB box, 480 GiB quantized on 512 GiB box, etc.

If the open weights models are good, there are people looking to sell commodity access to it, much like a cloud provider selling you compute.

It's probably a trade secret, but what's the actual per-user resource requirement to run the model?

Plus, most users don't want to host their own models. Most users don't care that OpenAI, Anthropic and Google have a monopoly on LLMs. ChatGPT is a household name, and most of the big businesses are forcing Copilot and/or Claude onto their employees for "real work."

This is "everyone will have an email server/web server/Diaspora node/lemmy instance/Mastodon server" all over again.

Once we start seeing Open AI and Anthropic getting into the certifications and testing they'll quickly become the gold standard. They won't even need to actually test anyone. People will simply consent to having their chat interactions analyzed.

The models collect more information about us than we could ever imagine because definitionally, those features are unknown unknowns for humans. For ML, the gaps in our thinking carry far richer information about is than our actual vocabularies, topics of interest, or stylometric idiosyncrasies.

There will come a day when you can will an entire business into existence at the press of a button. Maybe it has one or two people overseeing the business logic to make sure it doesn't go off the rails, but the point is that this is a 100x reduction in labor and a 100,000x speed up in terms of delivery.

They'll price this as a $1M button press.

Suddenly, labor capital cannot participate in the market anymore. Only financial capital can.

Suddenly, software startups are no longer viable.

This is coming.

The means of production are becoming privatized capital outlays, just like the railroads. And we will never own again.

There is nothing that says our careers must remain viable. There is nothing that says our output can remain competitive, attractive, or in demand. These are not laws.

Knowledge work may be a thing of the past in ten years' time. And the capital owners and hyperscalers will be the entirety of the market.

If we do not own these systems (and at this point is it even possible for open source to catch up?), we are fundamentally screwed.

I strongly believe that people not seeing this - downplaying this - are looking the other way while the asteroid approaches.

This. Is. The. End.

What if labor organizes around human work and consumers are willing to pay the premium?

At that point, it's an arms race against the SotA models in order to deepen the resolution and harden the security mechanisms for capturing the human-affirming signals produced during work. Also, lowering the friction around verification.

In that timeline, workers would have to wear devices to monitor their GSR and record themselves on video to track their PPG. Inconvenient, and ultimately probably doomed, but it could extend or renew the horizon for certain kinds of knowledge work.

We could start today, but sweat shops and factories dominate the items on our shelves.

But I’m sure people will draw the line at human made software…/s

If the barrier to button-pressed companies goes that high up, the cost to run/consume the product also goes up. Making hand-rolled products cheaper.

Slower paced to roll out things? Sure.

That's the precarious balance these LLMs providers have to make. They can't just move on without the people feeding it data and value. The machine is not perpetual.

What is far more likely is that governments use AI to oppress their citizens with robots and drones. That is the thing to be scared of.

The degree to which any business is sociopathic or psychopathic towards humans will be the limiting factor.

Microsoft is already working on turning the trust of their users into as many paperclips as possible

As long as they keep the original projects maintained and those aren't just acqui-hires, I think this is almost as good as we can hope for.

(thinking mainly about Bun here as the other one)

Once you’re acquired you have to do what the boss says. That means prioritizing your work to benefit the company. That is often not compatible with true open source.

How frequently do acquired projects seriously maintain their independence? That is rare. They may have more resources but they also have obligations.

And this doesn’t even touch on the whole commodification and box out strategy that so many tech giants have employed.

Or quit, and take the (Open Source) project and community with you. Companies sometimes discover this the hard way; see, for instance, the story of how Hudson became Jenkins.

Equivalent or better tools will pop up eventually, heck if AI is so fantastic then you could just make one of your own, be the change you want to see in the world, right?

If AGI becomes available, especially at the local and open-source level, shouldn't all these be democratized - meaning that the AGI can simply roll out the tooling you need.

After all, AGI is what all these companies are chasing.

Oh well. They’ll hopefully get options and make millions when the IPO happens. Everyone eventually sells out. Not everyone can be funded by MIT to live the GNU maximalist lifestyle.

Why on earth would agents ever code in as terrible a language as Python when the cost of significantly better languages is essentially free? The only advantage Python ever had was that it was easy to write

I can't believe people say this with a straight face

It's fast enough for many use cases. That doesn't mean that there is no room for optimization, but this is far less a deciding factor these days.

> it's not type safe

You can do static analysis with Mypy and other tools.

> it has not real concurrency.

There's different mechanisms for running things concurrently in Python. And there's an active effort to remove the GIL. I also have to ask: What is "real" concurrency?

Admittedly, the things you mention are not Python's strongest points. But they are far from being dealbreakers.

Everyone says this but its not really true. Every team I've seen do this immediately regrets it when they scale (like at all).

>You can do static analysis with Mypy and other tools.

Not even remotely the same

>There's different mechanisms for running things concurrently in Python. And there's an active effort to remove the GIL. I also have to ask: What is "real" concurrency?

Free threads. And yes this is a deal breaker in tons and tons of situations. I have no idea why people are soooo hard up for python

Is it? We still need meatspace humans to vet what these AI agents produce. Languages like C++ / Rust etc still require huge cognitive overhead relative to Python & that will not change anytime soon.

Unless the entire global economy can run on agents with minimal human supervision someone still has to grapple with the essential complexity of getting a computer to do useful things. At least with Python that complexity is locked away within the CPython interpreter.

Also an aside, when has a language ever gotten traction based solely on its technical merits? Popularity is driven by ease-of-use, fashion, mindshare, timing etc.

Overall the switch has been very much loved. Everything is faster and more stable, we haven't seen much of a reduction in output

And as someone who loves Python and has written a lot of it, I tend to agree. It's increasingly clear the way to be productive with AI coding and the way to make it reliable is to make sure AI works within strong guardrails, with testsuites, etc. that combat and corral the inherent indeterminism and problems like prompt injection as much as possible.

Getting help from the language - having the static tooling be as strict and uncompromising as possible, and delegating having to deal with the pain to AI - seems the right way.

There is also a really good ecosystem of libraries, especially for scientific computing. My experience has been that Claude can write good c++ code, but it's not great about optimization. So, curated Python code can often be faster than an AI's reimplementation of an algorithm in c++.

If I ask an LLM or agentic AI to build something and don't specify what language to use, I'd wager that it'll choose python most of the time. Casual programmers like academics or students who ask ChatGPT to help them write a function to do X are likely to be using Python already.

I'm not a Python evangelist by any means but to suggest that AI is going to kill Python feels like a major stretch to me.

EDIT: when I say that Python can do anything any other language can do, that's with the adage in mind. Python is the second best language for every task.

My last two companies went all in on python and really regretted it. It's performance and concurrency primitives really hurt as you scale

Secondly it's non factual. Python's market share grew in 2025[1][2][3]. Probably driven by AI demand.

[0]: even truer for natural languages.

[1]: https://survey.stackoverflow.co/2025/technology#most-popular...

[2]: https://survey.stackoverflow.co/2024/technology#most-popular...

[3]: https://pypl.github.io/PYPL.html

Do you really think AI agents of the future will be coding in Python??? What advantage would that possibly give them? That's the only laughable take here

Rust is great. But AI isn't displacing Python anytime soon.

Moreso it sucks that Astral's been bought by a company with such a horrible leader at the helm.

The ecosystem will be this way for a while, if not the new normal.

The GPL (and even the AGPL) doesn't require you to make your modified source code publicly available (Debian explicitly considers licenses with this requirement non-free). The GPL only states you need to provide your customers with source code.

https://x.com/AprilNEA/status/2034209430158619084

Ironically this type of stuff really makes me doubt their AGI claims, why would they bother with this stuff if they were confident of having AGI within the next few years? They would be focused on replacing entire industries and not even make their models available at any price. Why bother with a PaaS if you think you are going to replace the entire software industry with AGI?

Is this not just the strategy of all platforms. Spy on all customers, see what works for them and copy the most valuable business models. Amazon does that with all kinds of products.

Platforms will just grow to own all the market and hike prices and lower quality, and pay close to nothing to employees. This is why we used to have monopoly regulations before being greedy became a virtue.

Just wait till they offer "Developer Certification" so you have to pay them to get a shiny little badge and a certificate while they go around saying no badge = you're shit.

because AGI doesn't grow in a cage, it requires a piece of software running somewhere. someone has to build both to get that happen. that is like a high school level question.

even if this is true, someone needs to build the platform and the software required to get to the singularity.

one can also argue that lots of $ is required to get to the singularity, taking control of how the world builds, deploys and operates the digital world is a proven avenue to get such $.

Like having a system prompt which takes care of the project structure, languages, libraries etc

It's pretty much the first step to replacing devs, which is their current "North Star" (to be changed to the next profession after)

Once they've nailed that, the devs become even more of a tool then they're already are (from the perspective of the enterprise).

Ah yes, it was impossible to write software before these companies existed, and the only way to write software is via the products from these companies. They sure do control the "means of production".

Microsoft has been a reasonable steward of github and npm considering everything but I don't feel so good about OpenAI this makes me reconsider my use of uv and Python as a whole because uv did a lot to stop the insanity. Not least Microsoft has been around since 1975 whereas I could picture OpenAI vanishing instantly in a fit of FOMO.

All the passion and vision is gone from GitHub and NPM. They're now too big and too stale not to (eventually) be replaced by projects which do still have excitement and leadership

The point is that the value of accumulated know how and skill that lead to things like uv isn't lost even if the worst would happen to the company or people behind it. I don't think there are many signs of that. I don't think they had much of a revenue model around providing OSS tools. It's problematic for a lot of VC funded companies. An exit like this is as good as it gets. OpenAI now pays them to do their thing. Investors are probably pretty happy. And we maybe get to skip the enshittification that seems inevitable with the whole IPO/hedge funds circus that many vc funded OSS companies end up being subjected to. Problem solved. Congratulations to the team. They can continue doing what they love doing in a company that clearly loves all things python. And who knows what they can do next when freed from having to worry about making investors happy?

Big companies and OSS have always had symbiotic relationships. Some of the largest contributors to open source are people working in big companies. OpenAI fits this tradition beautifully. Most big software companies actively contribute to OSS projects that are relevant or important to them. Even very secretive companies like Apple or profit focused sharks like Oracle. Google, Meta, IBM. There are very few large software companies that aren't doing that. OSS without this very large scale corporate sponsor ships would just be a niche thing. Yes there are a lot of small projects. I have a few of my own even. But most of the big ones have some for profit businesses behind them.

The real meta question is of course if we still need a lot of the people centered development tooling when AIs are starting to do essentially all of the heavy lifting in terms of coding. I think we might need very different tools soon.

The fuck does OpenAI have to offer?

Nothing I need.

The only reason Gemini is the best is UX, really running my own Mistral 7b is more than fine.

Because slow ass Gemini is still a slightly more convenient experience I use that.

Nobody OWNS nor will own the means of essentially thoughts. It’s such a silly idea I wonder if it’s propaganda.

That's the problem isn't it. OpenAI have nothing to offer, neither does many of the other AI companies, nothing that's not replaceable at least.

They need to gobble up these other actors in an attempt to own something that someone might actually pay for. Anthropic seems successful with Claude Code and can drive sales that way.

OpenAI struggles to sell ChatGPT as a standalone offering, so they need products and services that will consume it, allowing them to push sales via that route. They also need to control those products, because LLMs are pretty much plug-able at this point, and that's no good. OpenAI needs a lock in.

That means OpenAI will be able to do whatever they want to your Python binaries, including every Python binary in your deployments, with whatever telemetry that want to instrument in the builds.

My question is if them gobbling up the alternatives will make room for other alternatives to grow.

I imagine many of these efforts benefitted the community as a whole, but it does make sense that the owners will have these orgs at least prioritize their own internal needs.