Breaking up with Python

Not conda, but using the built-ins should work for most use cases.

---

1. Create a virtual environment named venv

  cd $PROJECT_FOLDER
  python -m venv venv

2. Activate it.

  source ./venv/bin/activate

(In vscode, Ctrl+P > Select: Python Interpreter)

3. Define and install dependencies

  nano requirements.txt
  pip install -r requirements.txt

(or just "pip install ___")

If you are using conda, use its environment management:

https://docs.conda.io/projects/conda/en/latest/user-guide/ta...

(Lots of the other advice here—mamba excepted, and that might be a good choice—is good for python in general but potentially will cause problems if you are otherwise using anaconda.)

Java the language used to be so simple that it needed significant library usage to accomplish anything at all. It aimed for ‘safe C with classes’ and succeeded… in the enterprise where management was making technical decisions. After feeling the heat from C# it managed to catch up, mostly, to modern realities. Not a good beginner language, despite the simplicity.

PHP was not designed at all. It took a decade to make it more than a template processor. The biggest, by far, selling point was ease of deployment: ftp and done. Good if you want to display something in a browser. Learning programming, not so much.

Javascript is starting to become a sane language with ES6. It’s an accident of history that became an industry standard due to sheer power of will of browser companies. Tooling complexity in its ecosystem rivals, if not exceeds, that of C++. Recommending js s as a language to learn programming on has been until last couple of years irresponsible.

Python was designed to be beginner friendly, it was the next iteration of other beginner-friendly languages that had some academic research done about, you guessed it, beginner friendliness. It is not an accident it’s recommended for newbies! Due to that and a decade of 1) numpy for biological computing 2) django/flask for web services it’s ubiquitous in two very loosely connected domains, giving birth to jupyter and tensor libraries, and here we are. Turns out a batteries-included standard library makes packaging not a priority for too long.

>> Python is huge, the python:3.9-slim Docker image is 118MB

> Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.

Caching aside, it seems that the Python slim image is built on Debian, which will usually have slightly bigger container sizes than something like Alpine, which is comparatively more lightweight/barebones:

  > docker pull python:3.9-slim && docker image ls
  REPOSITORY   TAG        IMAGE ID       CREATED        SIZE
  python       3.9-slim   e2f464551004   8 days ago     125MB

  > docker run --rm python:3.9-slim sh -c "cat /etc/*-release"
  PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
  NAME="Debian GNU/Linux"
  
  > docker pull python:3.9-alpine3.17 && docker image ls
  REPOSITORY   TAG              IMAGE ID       CREATED        SIZE
  python       3.9-slim         e2f464551004   8 days ago     125MB
  python       3.9-alpine3.17   d6d1ed462b20   3 weeks ago    48.8MB
  
  > docker run --rm python:3.9-alpine3.17 sh -c "cat /etc/*-release"
  3.17.0
  NAME="Alpine Linux"

Now, I'm not saying that Alpine is the perfect base distro for your container images, despite it generally being a reasonable pick (I've heard some stories about Python performance in particular, and sometimes there are package related oddities), but the distro that you choose will most definitely have an effect on what you'll ship.

Of course, caching and any additional tools that you may or may not want to include also plays a part. Personally, I just went for maximum predictability and usability, and now build most of my personal container images basing them on Ubuntu LTS, with some common CLI tools included for debugging: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...

Just use whatever works for you, but rest assured that JDK and other stacks will typically also have some overhead to them. Python might not be the worst offender here. Something like Go with compiled binaries is still very nice, granted.

I do not understand the incentive structure that would lead anyone to believe such a low effort blog post brings anything to anyone. The points raised are very standard, have reasons and counterpoints, and finally just invoking Go and JS without any details is so meh...