There’s a lot to be said about his approach with go for simplicity. Python needs virtual environments, package managers, dependencies on disk, a wsgi/asgi server to run forked copies of the server, and all of that uses 4x-20x the ram usage of go. Docker usually gets involved around here and before you know it you’re neck deep in helm charts and cursing CNI configs in an EKS cluster.
The go equivalent of just coping one file across to a server a restarting its process has a lot of appeal and clearly works well for him.
Yes. It strikes me as odd how many people will put forward Python with the argument of "simplicity".
It is not. Simple. It may be "easy" but easy != simple (simple is hard, I tend to say).
I'm currently involved in a project that was initially layed out as microservices in rust and some go, to slowly replace a monolyth Django monstrosity of 12+ years tech debt.
But the new hires are pushing back and re-introducing python, eith that argument of simplicity. Sure, python is much easier than a rust equivalent. Esp in early phases. But to me, 25+ years developer/engineer, yet new to python, it's unbelievable complex.
Yes, uv solves some. As does ty and ruff. But, my goodness, what a mess to set up simple ci pipelines, a local development machine (that doesn't break my OS or other software on that machine). Hell, even the dockerfiles are magnitudes more complex than most others I've encountered.
"trivial" falls in the "easy" category. So it may not be hard to do. But what UV makes "easy" is managing something very complex under the hood.
Better example:
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
While "easy" it is nowhere near simple. Aside from the entire complexity of the stack of docker, that `python:3.9-slim` it itself is very complex. It installs over 20 "dev" packages (from bluetooth via tk to xz), it downloads source files, builds a python runtime, (patches that?), installs pip, setuptools, does some (to python people probably familiar?) "wheel" stuff, etc¹. Point being: what you end up with, while easy to get, is very complex.
uv manages a runtime, some virtual environment to hot-swap that with other runtimes, it hooks into a package manager, manages additional tools (linter, typechecker, lsp, etc) and so on. What lies under that is very complex.
¹ I am well aware that node, ruby, php are quite similar.
The go equivalent of just coping one file across to a server a restarting its process has a lot of appeal and clearly works well for him.