What excites me most about UV isn't just the speed improvement, but how it demonstrates a key principle in modern developer tooling: removing friction should never mean removing choice.
I've been following this discussion about project-centric vs. environment-centric workflows, and I think UV actually enables both patterns quite well. For the "fiddle around until something emerges" workflow that @BrenBarn mentioned, you can absolutely create a general-purpose environment with `uv venv playground` and then use `uv pip install` to gradually build up your experimental dependencies. The project structure can come later.
What's interesting is how UV's speed makes the cost of switching between these approaches nearly zero. Want to quickly test something in isolation? Spin up a temporary environment. Want to formalize an experiment into a project? The migration is painless.
This mirrors what I've seen in other parts of the toolchain - tools like Vite for frontend dev or modern Docker practices all follow this pattern of "fast by default, but flexible when you need it." The velocity improvements compound when your entire toolchain operates on this principle.
I think better developer tools tend to compound over time, they raise expectations and push the whole ecosystem forward.
IMO, uv is quickly becoming one of the best reasons to start a new project in Python. It’s fast, and brings a level of polish and performance that makes Python feel modern again.
Indeed. It's interesting to compare the expectations of a new programming language today to just a decade ago for instance.
The funky thing is that people will fork uv and make package managers for other programming languages from it. Or at least from parts of it. Win win.
I think uv is one of the best examples of why not to start a new project in Python. I mean, depending on the project really, Python has its place. But if your project is anything like uv, uv proves you can't actually write an app like uv in Python. So for as great as uv is, its proximity to Python is a constant reminder of its shortcomings.
A car doesn't move as fast as an airplane can.
Therefore, cars are useless and nobody should use one.
I had said: "I mean, depending on the project really, Python has its place."
My point is if you put an airplane next to a car factory, it's very clear you can't build the airplane in the car factory.
and yet still no one should try to use a car to deliver packages overnight across the country.
I was thinking that this morning as the plane dropped off my overnight package.
So the airplane will be landing at your house?