@hynek @glyph I don't think anyone is objecting to Rust as a reasonable technical choice for this kind of tooling. But we do have to realistic about it shrinking the potential future maintainers pool by a lot which is a downside to weigh against the benefits. And with paid contributors right now is kind of masks the downside in a way that many of us who have been on the receiving end of this cycle before find concerning.

@coderanger @hynek 100%, and I am definitely not complaining when I use a project that's adopted uv and ruff and everything is almost implausibly fast. it's not really a *bottleneck* in my other projects, but I certainly don't mind the focus on performance that comes along with the choice of Rust.

I certainly don't object to Rust *qua* Rust, I depend on mountains of it in Cryptography and I wish I depended on more. but that's a different element of the stack with a very different context.

@hynek @coderanger I feel like somewhere a Homebrew maintainer is muttering "challenge accepted"

@hynek @glyph @coderanger This is such an underemphasized point. My team is responsible for the dev tooling at my employer, and I’m *so* delighted about uv, even as I’m also very skeptical about their business model.

@hynek @glyph @coderanger hm, never thought of this argument but it very much checks out

@hynek @glyph @coderanger as a user of micromamba, and now pixi, which did that for the conda world, I agree 100% with this. It is so much easier to setup an env from the ground up. Teaching is much easier, maintaining scientific environments consistent across multiple machines became much easier, everything is easier in that form. Single binary, no dependencies, quick to bootstrap anything python related with few commands and consistent instructions across multiple OSes.

@hynek @glyph @coderanger I will probably be unable to make the time to read the licensing position but as long as it’s forkable, it should be fine, no?

There is quite some overlap in the Venn diagram of Python and Rust programmers and in the best case the tooling opens more channels between the two communities.

@hynek @glyph @coderanger I signed up for Mastodon just to post this 😅

I spent a significant amount of time making it so that Hatch also provides a similar experience such that it's the only tool you need to download manually. Installation takes 1-3 seconds and I don't think I can make it any faster, technically.

Example run locally and on GitHub Actions from here https://github.com/tox-dev/platformdirs/actions/runs/10758318125/job/29833485691:

@hynek @glyph @coderanger 1000%

@hynek @glyph @coderanger mojo and Julia can also create small binaries. There is a path to those languages from a rpython-like statically typed dialect.

@ofek @glyph @coderanger yeah I mention PyApp in some side-thread WRT Hatch has (indirectly) Rust inside too, to unjank the Python-ness :D

@tintvrtkovic @hynek @glyph @coderanger Agreed, this is the killer advantage of *any* compiled language over one with a runtime. And to make it worse, Python is far from being the best runtime based language for app deployment :-(

@pfmoore @tintvrtkovic @glyph @coderanger The fact that now I can give anyone a Python project and uv and tell them to “just run `uv run X` in the project folder” and it will take about everything including installing Python is nothing short of magic. There’s a short line to running Zip files.

@pfmoore @tintvrtkovic @hynek @coderanger interesting that "compiled" and "with a runtime" are the opposite ends of the spectrum here :). (I get what you're saying, but it is _possible_ to do this with Python, and a real shame that "rewrite in a different language" is actually an easier path than just using existing tooling)

@hynek @tintvrtkovic @glyph @coderanger Agreed. But to be fair, that's the way hatch and pdm are going as well. And a lot of uv's speed comes from language-agnostic tricks like aggressive caching. All of this could have been done in existing projects. It's funding and full time employees that has made the huge difference.