7 ms·

Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions.

mastermage 7mo ago
I dont wanna go back to micromamba, pixi is my happy place (which builds on uv).
tomrod 7mo ago
Maybe you could. I would stare longingly into the void, wondering if I can ever work another python project after having experienced uv, ruff, and ty. 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."
- giancarlostoro 7mo ago
  It is an MIT licensed project, someone will absolutely fork it.
  - WesolyKubeczek 7mo ago
    You seem to be underestestimating the laziness of the people, and overestimating their resolve. Angry forks usually don't last, angst doesn't prevent maintenance burnouts.
    - jitl 7mo ago
      clicking "fork" in github is pretty easy
      - WesolyKubeczek 7mo ago
        If you think clicking “fork” is all there is to it, I have some bad news for you.
    - giancarlostoro 7mo ago
      You underestimate the value that something like uv and company bring to the ecosystem. Given enough time I could have seen it replacing some core utilities, now that its owned by OpenAI I don't see that happening, unless OpenAI "donates" the project but keeps the devs on a payroll.
    - deleted 7mo ago
      [deleted]
- signal11 7mo ago
  I was using poetry pretty happily before uv came along. I’d probably go back. 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 https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html
  - theLiminator 7mo ago
    Maybe I could give up uv, but giving up ruff would suck.
    - crdrost 7mo ago
      This is just the weirdest thread. 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.
      - asa400 7mo ago
        The leadership and product direction work are at least as hard as the code work. Astral/uv has absolutely proven this, otherwise Python wouldn't be a boneyard for build tools. 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.
        PaulHoule 7mo ago
- deadbabe 7mo ago
  Maybe consider something other than python.
  - scuff3d 7mo ago
    Good luck with that. I haven't been successful at convincing anyone to move away from it. I'm so fucking sick of writing Python at work lol
    - tomrod 7mo ago
      Why?
      - scuff3d 7mo ago
        Because I hate dynamically typed languages for anything besides scripting and glue code. 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
    - Chris2048 7mo ago
      What would you prefer to use?
      - scuff3d 7mo ago
        Just about anything, as long as it's statically typed. The domain I work in is basically perfect for Go, so I've been pushing for that.
  - tomrod 7mo ago
    Always choose the best tool for the job. Then import that tool and and check if __name__ == "__main__"
- FreakLegion 7mo ago
  Ruff is performant but finds about half the issues Pylint does (see https://github.com/astral-sh/ruff/issues/970 https://github.com/astral-sh/ruff/issues/970). Ty is quantitatively the worst of the well-known type checkers (see https://news.ycombinator.com/item?id=47398023 https://news.ycombinator.com/item?id=47398023). Uv is Astral's only winner.
  - blazarquasar 7mo ago
    You are aware that ty has only recently entered beta status? 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.
    - fud101 7mo ago
      >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.
    - FreakLegion 7mo ago
      Reread the comment I replied to: > 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.
crimsoneer 7mo ago
Eurgh, I do not want to ever touch Poetry or pyenv again, thank you very much.
giancarlostoro 7mo ago
While I hope it never comes to that, all the code is MIT licensed, I would assume everyone would make the sensible decision for fork it.
alsetmusic 7mo ago
I see Apache and MIT license files in their GitHub. What's to prevent the community from forking and continuing development if the licenses change?
- eviks 7mo ago
  The same things that prevented "community" from building the tool in the first place
  - johnisgood 7mo ago
    Cannot we at one point consider the tool to be "done"? I mean, what is there to constantly change and improve? Genuinely curious. It sounds like a tool that can be finished. Can it not be?
    - influx 7mo ago
      You’d be surprised how many features the Python runtime adds each release. It’s not trivial for tooling to keep up with language changes.
    - eviks 7mo ago
      So why isn't pip done?
  - zem 7mo ago
    that makes zero sense to me. developing something like ruff from scratch takes a lot of things happening - someone having the idea, the time to develop it from scratch in their free time, or the money to do it as a job, and perhaps the need to find collaborators if it's too large a project for one person. but now ruff is there, there's no need to build it from scratch. if I wanted to build a python linter or formatter I would simply fork ruff and build on top of it. as others have said in this subthread, that's the whole point of open source!
    - eviks 7mo ago
      > the time to develop it [not] from scratch in their free time, or the money... 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
skywhopper 7mo ago
I mean, if you believe the hype on this website, Claude Code could build a perfect clone of uv in a few hours using only the documentation.
arw0n 7mo ago
Ruff is nice, but not important, uv is one of the few things making the python ecosystem bearable. Python is a language for monkeys, and if you don't give monkeys good tools, they will forever entangle themselves and you. It is all garbage wrapped in garbage. At least let me deploy it without having to manually detangle all that garbage by version. 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.
- aprdm 7mo ago
  Python existed for years before uv with a huge ecosystem, and will continue to do so after/if it dies
  - Terretta 7mo ago
    uv, yes*, but really PEP 723: https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/ * disclosure: We are a commercial client of astral.sh
    - notpushkin 7mo ago
      It’ll probably be a game changer for scripts, yes. Writing “portable” Python scripts was a nice exercise, though (and will be, for a while).
    - the__alchemist 7mo ago
      This is cool! I ended up also inventing my own syntax to place at the top of one-off scripts to specify deps. (For single-file Python scripts, vs one with a full project dir that has pyproject.toml) I will adopt this instead.
    - shurane 7mo ago
      Sounds a lot like vim/emacs modelines. This is neat for standalone scripts.
wiseowise 7mo ago
I would just ditch Python, like I did 8 years ago.
MidnightRider39 7mo ago
Personally I would stop using Python again. uv is the one thing that made it bearable.
sdevonoes 7mo ago
I wish that were also true for the case of Claude/Codex/etc
crypto137 7mo ago
UV is so much nicer than the other options.
linsomniac 7mo ago
>Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions. Or, more relevant to this conversion: If they closed source tomorrow, the community could fork the current version.
bbor 7mo ago
…if tomorrow python ceased to exist, we could all go back to any number of other solutions.

I dont wanna go back to micromamba, pixi is my happy place (which builds on uv).

Maybe you could. I would stare longingly into the void, wondering if I can ever work another python project after having experienced uv, ruff, and ty. 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."

giancarlostoro 7mo ago
It is an MIT licensed project, someone will absolutely fork it.
- WesolyKubeczek 7mo ago
  You seem to be underestestimating the laziness of the people, and overestimating their resolve. Angry forks usually don't last, angst doesn't prevent maintenance burnouts.
  - jitl 7mo ago
    clicking "fork" in github is pretty easy
    - WesolyKubeczek 7mo ago
      If you think clicking “fork” is all there is to it, I have some bad news for you.
  - giancarlostoro 7mo ago
    You underestimate the value that something like uv and company bring to the ecosystem. Given enough time I could have seen it replacing some core utilities, now that its owned by OpenAI I don't see that happening, unless OpenAI "donates" the project but keeps the devs on a payroll.
  - deleted 7mo ago
    [deleted]
signal11 7mo ago
I was using poetry pretty happily before uv came along. I’d probably go back. 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 https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html
- theLiminator 7mo ago
  Maybe I could give up uv, but giving up ruff would suck.
  - crdrost 7mo ago
    This is just the weirdest thread. 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.
    - asa400 7mo ago
      The leadership and product direction work are at least as hard as the code work. Astral/uv has absolutely proven this, otherwise Python wouldn't be a boneyard for build tools. 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.
      - PaulHoule 7mo ago
deadbabe 7mo ago
Maybe consider something other than python.
- scuff3d 7mo ago
  Good luck with that. I haven't been successful at convincing anyone to move away from it. I'm so fucking sick of writing Python at work lol
  - tomrod 7mo ago
    Why?
    - scuff3d 7mo ago
      Because I hate dynamically typed languages for anything besides scripting and glue code. 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
  - Chris2048 7mo ago
    What would you prefer to use?
    - scuff3d 7mo ago
      Just about anything, as long as it's statically typed. The domain I work in is basically perfect for Go, so I've been pushing for that.
- tomrod 7mo ago
  Always choose the best tool for the job. Then import that tool and and check if __name__ == "__main__"
FreakLegion 7mo ago
Ruff is performant but finds about half the issues Pylint does (see https://github.com/astral-sh/ruff/issues/970 https://github.com/astral-sh/ruff/issues/970). Ty is quantitatively the worst of the well-known type checkers (see https://news.ycombinator.com/item?id=47398023 https://news.ycombinator.com/item?id=47398023). Uv is Astral's only winner.
- blazarquasar 7mo ago
  You are aware that ty has only recently entered beta status? 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.
  - fud101 7mo ago
    >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.
  - FreakLegion 7mo ago
    Reread the comment I replied to: > 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.

crimsoneer 7mo ago

Eurgh, I do not want to ever touch Poetry or pyenv again, thank you very much.

giancarlostoro 7mo ago

While I hope it never comes to that, all the code is MIT licensed, I would assume everyone would make the sensible decision for fork it.

alsetmusic 7mo ago

I see Apache and MIT license files in their GitHub. What's to prevent the community from forking and continuing development if the licenses change?

eviks 7mo ago
The same things that prevented "community" from building the tool in the first place
- johnisgood 7mo ago
  Cannot we at one point consider the tool to be "done"? I mean, what is there to constantly change and improve? Genuinely curious. It sounds like a tool that can be finished. Can it not be?
  - influx 7mo ago
    You’d be surprised how many features the Python runtime adds each release. It’s not trivial for tooling to keep up with language changes.
  - eviks 7mo ago
    So why isn't pip done?
- zem 7mo ago
  that makes zero sense to me. developing something like ruff from scratch takes a lot of things happening - someone having the idea, the time to develop it from scratch in their free time, or the money to do it as a job, and perhaps the need to find collaborators if it's too large a project for one person. but now ruff is there, there's no need to build it from scratch. if I wanted to build a python linter or formatter I would simply fork ruff and build on top of it. as others have said in this subthread, that's the whole point of open source!
  - eviks 7mo ago
    > the time to develop it [not] from scratch in their free time, or the money... 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

skywhopper 7mo ago

I mean, if you believe the hype on this website, Claude Code could build a perfect clone of uv in a few hours using only the documentation.

arw0n 7mo ago

Ruff is nice, but not important, uv is one of the few things making the python ecosystem bearable. Python is a language for monkeys, and if you don't give monkeys good tools, they will forever entangle themselves and you. It is all garbage wrapped in garbage. At least let me deploy it without having to manually detangle all that garbage by version. 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.

aprdm 7mo ago
Python existed for years before uv with a huge ecosystem, and will continue to do so after/if it dies
- Terretta 7mo ago
  uv, yes*, but really PEP 723: https://peps.python.org/pep-0723/ https://peps.python.org/pep-0723/ * disclosure: We are a commercial client of astral.sh
  - notpushkin 7mo ago
    It’ll probably be a game changer for scripts, yes. Writing “portable” Python scripts was a nice exercise, though (and will be, for a while).
  - the__alchemist 7mo ago
    This is cool! I ended up also inventing my own syntax to place at the top of one-off scripts to specify deps. (For single-file Python scripts, vs one with a full project dir that has pyproject.toml) I will adopt this instead.
  - shurane 7mo ago
    Sounds a lot like vim/emacs modelines. This is neat for standalone scripts.

wiseowise 7mo ago

I would just ditch Python, like I did 8 years ago.

MidnightRider39 7mo ago

Personally I would stop using Python again. uv is the one thing that made it bearable.

sdevonoes 7mo ago

I wish that were also true for the case of Claude/Codex/etc

crypto137 7mo ago

UV is so much nicer than the other options.

linsomniac 7mo ago

>Sure, but if tomorrow uv and ruff ceased to exist, we could all go back to any number of other solutions. Or, more relevant to this conversion: If they closed source tomorrow, the community could fork the current version.

bbor 7mo ago

…if tomorrow python ceased to exist, we could all go back to any number of other solutions.