Hacker News Reader

Comment by Tenemo | Hacker News Reader

Do you think e.g. students learning docker syntax at a uni is beneficial in 2026 or you think LLM-assisted programming means that Docker will become an abstraction under an abstraction and its setup will be mostly automated by LLMs? I find myself very rarely debugging or handwriting dockerfiles nowadays!

View on HN

This is a strange question because you could learn Dockerfile syntax in a single night. There are only 18 directives, and the average Dockerfile uses like 6 of them. 90%+ of Dockerfiles is just "run this shell command" and "copy this file into the docker image". The only time it flirts with complexity is multi-stage Dockerfiles, but 90%+ of Dockerfiles are a single stage.

https://docs.docker.com/reference/dockerfile/

> The only time it flirts with complexity is multi-stage Dockerfiles, but 90%+ of Dockerfiles are a single stage.

And multi stage builds are just a directed graph short hand for having separate intermediate dockerfiles. There’s nothing special about them either.

If I had to pick one thing that is tricky for someone new to docker to understand, it’s how the filesystem state is cached using the previous state, the env, and the raw command text.

Indeed, the one mistake I keep seeing new people make when writing Dockerfiles is writing them in a way that doesn't optimize for caching. For example, they'll copy their code into the container first and then start installing packages and dependencies. It's an easy mistake to make because the end result is still a functional Dockerfile, they're just wasting time and stressing the poor package servers unnecessarily.

Or multi-container compose files with atypical networking, or troubleshooting daemon permission issues.

Docker is much more than memorising a handful of Dockerfile directives.

I think the key thing for a university student is to get the big ideas down: what is a container exactly, how does it work, how does it differ from a VM, what assumptions does it make about what you're running (and how do you run something that doesn't fit that pattern), why do images exist in layers and how are layers implemented, what are the performance benefits/tradeoffs, etc. etc.

When I was learning Docker I can't tell you how many people would describe it to me by analogy to a standardized shipping container, and start going off about shipping container dimensions and supersized cargo ships and trucks and railcars... and finish by smiling beatifically, like they had just explained the whole thing in a masterstroke. Let's... uh... not do that. :-D

In a problem set, the student might learn a bit about dockerfiles or docker-compose.yml... but only, I think, so they can try building and running a container of their own!

I'm gonna be real with you. No one needs to know docker syntax. Most engineers just copy and paste chunks of Dockerfiles around anyways.

Docker syntax is one of those things that just immediately falls out of my head when I close the editor. I don't care about it at all.

Even better: there are many, many tools that build OCI images without using the Docker syntax. I haven't hand-written a Dockerfile in at least six years.

LLMs have not loved the needle here in my sphere, it was already bouncing off of the zero on the gauge.

edit: this isn't to say the syntax is good or bad (though there are several questionable parts of it) but extremely simple, and concise enough that you can just look up literally any command with great ease. It's surely a large part of its success, for better or for worse.

I find the Dockerfile syntax easier to use than any if the tools that generate it indirectly.

If you're going to fully delegate something so trivial as Dockerfiles to slopmachines, why go to university at all? You don't need to learn anything if you delegate everything to the slopmachine.

Reply on news.ycombinator.com