[KronisLV]

>> 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.