5 ms·

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked bac

Now we should just figure out why to stop here. Why not write everything in Rust? Recently I have moved all my projects to Rust from Python and never looked back. Of course we need projects like Torch and we are not yet there, but those simpler projects that do not require GPU libraries Rust is great.

gyomu 2y ago
What’s a good flask (+jinja) equivalent for rust?
- selectnull 2y ago
  Actix + minijinja Actix is just one of many web frameworks, minijinja is an implementation of jinja2, by the original author.
- datadeft 2y ago
  I use Axum and Askama for such usecases.
wiseowise 2y ago
Maybe because there would be blood on the streets, because people would start killing each other over atrocious build times?
- datadeft 2y ago
  Interesting. So pip install times did not make them to kill each other and the result is sometimes works, but if we wait on cargo build somehow it triggers them.
  - lmm 2y ago
    You can get pretty far without needing to run pip. Whereas you can't change anything in a rust codebase without compiling it.
procaryote 2y ago
It's a lot harder to write rust than python.
- datadeft 2y ago
  If you check the TCO than probably it pays off. I am not sure about how much harder it is. I do not use lifetimes and I clone a lot. Still the performance and the reliability a Rust project has vs. Python is insane.
  - procaryote 2y ago
    I think it depends a lot on what the task is.
Kwpolska 2y ago
Yeah, if Python sucks at managing its own packages and you need Rust, why use Python at all?
- zahlman 2y ago
  That's the thing: you don't actually need Rust. uv has simply chosen it as an implementation language, but there isn't anything about Python that inherently prevents it from being used to write tools better than Pip. The problems with Pip are problems with Pip, not problems with Python. (And many of them are completely fake, anyway. You don't actually need to spend an extra 15MB of space, and however many seconds of creation time, on a separate copy of Pip in each venv just so that Pip can install into that venv. You just need the `--python` flag. Which is a hack, but an effective one.) (Last I checked, the uv compiled binary is something like 35MB. So sticking with a properly maintained Pip cuts down on that. And Pip is horrendously bloated, as Python code goes, especially if you only have the common use cases.)
EdwardDiego 2y ago
Because Rust isn't Python. Feel like that's super-obvious but yet here we are.
zahlman 2y ago
"It's written in Rust" is not responsible for most of the improvements on offer here. (TFA barely mentions Rust, to its credit.) Many of them come from algorithmic improvements, better design decisions, and simply just not having the tool reside in the same environment as the installation target. (It is perfectly possible to use Pip cross-environment like this, too. People just don't do it, because a) they don't know and b) the standard library `venv` and `ensurepip` tools are designed to bootstrap Pip into new virtual environments by default. My recent blog post https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... offers relevant advice here, and upcoming posts are in the works and/or planned about design issues in Pip.) If your purpose is to denigrate Python as a language, then uv isn't solving problems for you anyway. But I will say that the kind of evangelism you're doing here is counterproductive, and is the exact sort of thing I'd point to when trying to explain why the project of integrating Rust code into the Linux kernel has been so tumultuous.
- datadeft 2y ago
  Do you think that pip could be re-implemented in Python and it would result in this performance that we are observing with uv?
  - zahlman 2y ago
    I don't suppose it could be as fast as uv is, but it could be much closer to that than where it is now. One immediate speed-up that requires no code changes: when uv creates a venv, it doesn't have to install Pip in that venv. You can trivially pass `--without-pip` to the standard library venv to do this manually. On my system: $ time uv venv uv-test Using CPython 3.12.3 interpreter at: /usr/bin/python Creating virtual environment at: uv-test Activate with: source uv-test/bin/activate real 0m0.106s user 0m0.046s sys 0m0.021s $ time python -m venv --without-pip venv-test real 0m0.053s user 0m0.044s sys 0m0.009s For comparison: $ time python -m venv venv-test real 0m3.308s user 0m3.031s sys 0m0.234s (which is around twice as long as Pip actually takes to install itself; I plan to investigate this in more detail for a future blog post.) To install in this environment, I use a globally installed pip (actually the one vendored by pipx), simply passing the `--python` argument to tell it which venv to install into. I have a few simple wrappers around this; see https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... for details. In my own project, Paper, I see the potential for many immediate wins. In particular, Pip's caching strategy is atrocious. It's only intended to avoid the cost of actually hitting the Internet, and basically simulates an Internet connection to its own file-database cache in order to reuse code paths. Every time it installs from this cache, it has to parse some saved HTTP-session artifacts to get the actual wheel file, unpack the wheel into the new environment, generate script wrappers etc. (It also eagerly pre-compiles everything to .pyc files in the install directory, which really isn't necessary a lot of the time.) Whereas it could just take an existing unpacked cache and hard-link everything into the new environment.

gyomu 2y ago

What’s a good flask (+jinja) equivalent for rust?

selectnull 2y ago
Actix + minijinja Actix is just one of many web frameworks, minijinja is an implementation of jinja2, by the original author.
datadeft 2y ago
I use Axum and Askama for such usecases.

wiseowise 2y ago

Maybe because there would be blood on the streets, because people would start killing each other over atrocious build times?

datadeft 2y ago
Interesting. So pip install times did not make them to kill each other and the result is sometimes works, but if we wait on cargo build somehow it triggers them.
- lmm 2y ago
  You can get pretty far without needing to run pip. Whereas you can't change anything in a rust codebase without compiling it.

procaryote 2y ago

It's a lot harder to write rust than python.

datadeft 2y ago
If you check the TCO than probably it pays off. I am not sure about how much harder it is. I do not use lifetimes and I clone a lot. Still the performance and the reliability a Rust project has vs. Python is insane.
- procaryote 2y ago
  I think it depends a lot on what the task is.

Kwpolska 2y ago

Yeah, if Python sucks at managing its own packages and you need Rust, why use Python at all?

zahlman 2y ago
That's the thing: you don't actually need Rust. uv has simply chosen it as an implementation language, but there isn't anything about Python that inherently prevents it from being used to write tools better than Pip. The problems with Pip are problems with Pip, not problems with Python. (And many of them are completely fake, anyway. You don't actually need to spend an extra 15MB of space, and however many seconds of creation time, on a separate copy of Pip in each venv just so that Pip can install into that venv. You just need the `--python` flag. Which is a hack, but an effective one.) (Last I checked, the uv compiled binary is something like 35MB. So sticking with a properly maintained Pip cuts down on that. And Pip is horrendously bloated, as Python code goes, especially if you only have the common use cases.)

EdwardDiego 2y ago

Because Rust isn't Python. Feel like that's super-obvious but yet here we are.

zahlman 2y ago

"It's written in Rust" is not responsible for most of the improvements on offer here. (TFA barely mentions Rust, to its credit.) Many of them come from algorithmic improvements, better design decisions, and simply just not having the tool reside in the same environment as the installation target. (It is perfectly possible to use Pip cross-environment like this, too. People just don't do it, because a) they don't know and b) the standard library `venv` and `ensurepip` tools are designed to bootstrap Pip into new virtual environments by default. My recent blog post https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... offers relevant advice here, and upcoming posts are in the works and/or planned about design issues in Pip.) If your purpose is to denigrate Python as a language, then uv isn't solving problems for you anyway. But I will say that the kind of evangelism you're doing here is counterproductive, and is the exact sort of thing I'd point to when trying to explain why the project of integrating Rust code into the Linux kernel has been so tumultuous.

datadeft 2y ago
Do you think that pip could be re-implemented in Python and it would result in this performance that we are observing with uv?
- zahlman 2y ago
  I don't suppose it could be as fast as uv is, but it could be much closer to that than where it is now. One immediate speed-up that requires no code changes: when uv creates a venv, it doesn't have to install Pip in that venv. You can trivially pass `--without-pip` to the standard library venv to do this manually. On my system: $ time uv venv uv-test Using CPython 3.12.3 interpreter at: /usr/bin/python Creating virtual environment at: uv-test Activate with: source uv-test/bin/activate real 0m0.106s user 0m0.046s sys 0m0.021s $ time python -m venv --without-pip venv-test real 0m0.053s user 0m0.044s sys 0m0.009s For comparison: $ time python -m venv venv-test real 0m3.308s user 0m3.031s sys 0m0.234s (which is around twice as long as Pip actually takes to install itself; I plan to investigate this in more detail for a future blog post.) To install in this environment, I use a globally installed pip (actually the one vendored by pipx), simply passing the `--python` argument to tell it which venv to install into. I have a few simple wrappers around this; see https://zahlman.github.io/posts/2025/01/07/python-packaging-2/ https://zahlman.github.io/posts/2025/01/07/python-packaging-... for details. In my own project, Paper, I see the potential for many immediate wins. In particular, Pip's caching strategy is atrocious. It's only intended to avoid the cost of actually hitting the Internet, and basically simulates an Internet connection to its own file-database cache in order to reuse code paths. Every time it installs from this cache, it has to parse some saved HTTP-session artifacts to get the actual wheel file, unpack the wheel into the new environment, generate script wrappers etc. (It also eagerly pre-compiles everything to .pyc files in the install directory, which really isn't necessary a lot of the time.) Whereas it could just take an existing unpacked cache and hard-link everything into the new environment.