[kernelbugs]

I believe parent comment was about `env -S` not being portable rather than `uv` being portable.

I'll say, I am as pessimistic as the next person about new ways to do X just to be hip. But as someone who works on many different Python projects day to day (from fully fledged services, to a set of lambdas with shared internal libraries, to CI scripts, to local tooling needing to run on developer laptops) - I've found uv to be particularly free of many sharp edges of other solutions (poetry, pipenv, pyenv, etc).

I think the fact that the uv tool itself is not written in Python actually solves a number of real problems around bootstrapping and dependency management for the tool that is meant to be a dependency manager.

[bmitc]

> I think the fact that the uv tool itself is not written in Python

It's interesting that the language people choose to write systems with (Python) is basically identified as not the best language to write systems to support that language (Python).

To my knowledge, no other mainstream language has tooling predominantly written in another language.

[IshKebab]

Javascript has quite a lot of tooling written in other (better) languages.

I think Javascript and Python stand out because they are both extremely popular and also not very good languages, especially their tooling. You're obviously going to get a load of people using Javascript and Python saying "why is Webpack/Pip so damn slow? I don't have any choice but to use this language because of the web/AI/my coworkers are idiots, so I may as well improve the tooling".

[kloop]

I believe quite a bit of the JS tooling has been rewritten in other languages over the last decade or so

[HelloNurse]

It's important to use any other language to avoid even the theoretical possibility of bootstrapping complications. All languages that produce self-contained compiled executables are equally suitable for the task.

[disgruntledphd2]

gcc is written in C++ for like a decade now, so it's not completely unusual.