> Especially when uv solves literally all of the problems you're describing.

How does uv solve the “write once, run anywhere” problem like go?

(I’m not being sarcastic, I don’t know that much about uv and perhaps am lacking the mental model for understanding this)

> How does uv solve the “write once, run anywhere” problem like go?

Here's an examply Python script from the uv website[0]:

  #!/usr/bin/env -S uv run --script
  #
  # /// script
  # requires-python = ">=3.12"
  # dependencies = ["httpx"]
  # ///

  import httpx

  print(httpx.get("https://example.com"))

This will auto-install Python 3.12 (or greater) in a per-script virtual environment, along with the httpx package from pypi & immediately execute the script, on any system that has uv.

[0] https://docs.astral.sh/uv/guides/scripts/#using-a-shebang-to...

UV is a drop-in for pip, rather than a replacement. It functions differently than pip behind the scenes, which is why it's faster, but when you use it, it's basically still pip. Except it makes everything easy. You create your venv with uv venv, you update packages with uv sync, you run things without activating your venv with uv run... It uses the pyproject.toml, so it's very easy to share things like linters and build tools. Then when it's time to deploy, you can compile your pyproject.toml to a requirements.txt file and use it in any Python container image. Which is very handy when you work with something like Azure Container Functions which don't come with UV (and you probably don't want to use an UV image or install UV in your build process).

I've been using it for so long now that I recently couldn't remember how to use Python without it, when one of our BI guys needed some help. Which was ridiculously embarrassing.

I don't think it really compares to Go though. It's not as straight forward if you work on different python distributions. It's also not as easy to work with something like micro Python compared to targeting a specific embedded platform with Go.