True! there are lots of layers of abstraction written around that core `nsenter` piece of libcontainer. I just take issue with the "Go is kind of a terrible language for a container runtime" claim made by the OP. The maintainers' choice to use an expressive high-level language for most of the codebase is a practical one, I think. They also knew when it was not the right tool for the job and when to pull out the C bindings or how to work-around issues with forking the process. The OP mentions this, but for fork/re-exec helpers in the engine, this is where it lives now: [1]. I specifically remember needing to use something like this for the `docker-untar` helper during image pulls (I worked primarily on the container image filesystem-setup part of Docker) so that extraction of the image layer archives could be done in a chroot with fewer privileges. It was a security-sensitive part of the docker daemon and previously there were all sorts of malicious ways that a container image could be built so that contents are extracted _outside_ of the place they should be. This is the "images are just folders" part of OP's article. Another part I find funny is the "Containers really aren’t real". I think the best part of this is that when you use docker to "create" a container (`docker container create`), it mostly just creates the container's rootfs directory (it's actually multiple directories combined using an Overlay Filesystem) and its configuration file. The container doesn't actually "exist" until the process starts which is a separate command (`docker container start`) because Docker doesn't actually instantiate the namespaces or launch the container task until start time (and generally in Linux, namespaces are tied to living processes unless explicitly held open via bind mounts or another process reading a `/proc` file).
[1] https://github.com/moby/sys/tree/main/reexec