Dockerizing a Programming Language | Hacker News Reader

Dockerizing a Programming Language

bellmar.medium.com

56 pointsmbellotti15 comments

OP is using Docker + Make in a similar way to how I was a few years ago, before I started using Toast (https://github.com/stepchowfun/toast). Toast lets you define tasks like you would with Make (without all the hairy gotchas of Makefiles), but it runs them inside Docker containers for better portability/reproducibility.

I see the benefit of Toast (or Make) if you aren't writing your own container and just want to add a couple of things to an existing container (eg a CI pipeline).. but if you are building a container, including them in the Dockerfile makes more sense, no?

In this particular case it looks like the author is reusing the makefiles used from other builds ("you should also be able to build the compiler from source and run it outside of the container") rather than duplicating the work, and she finds makefiles "to be soothing".

I get the arguments for using containers, but why use Docker? Especially if you're already using Make? Building a container image is pretty simple in Make (or bash, or anything else); you just copy a "config.json" into the output directory, tar it up, and write its sha256 to a "manifest.json" file.

Update: If you want to include other "layers", e.g. if the Z3 project provides its own image, then just put their SHA256 in the manifest.json too.

Doesn't docker seem overkill compared to just a package for a package manager or statically compiling Z3 into your binary?

When you're running multiple projects expecting the same globally installed library or shell command (but a different version), building/running in docker is a breeze: each container can have its own set of dependency versions.

> globally installed library or shell command

There's your problem! Different versions of anything can coexist if they're installed to separate locations; e.g. Nix does this by using the `--prefix` option of each project's './configure' script.

Docker is just another solution to the problem.

It's a rather convoluted one though: rather than telling libraries to install in different places, they're installed "globally" within a chroot, which then gets tarred-up, which then gets untarred, then bind-mounted, then chrooted-into again.

A cross platform solution, which is nice.

It's not "cross-platform" at all, since Docker builds on Linux containers. For example, the Docker applications for Windows and macOS just run a Linux VM behind the scenes.

AFAIK you can't run Windows binaries using Docker, even if you're using Windows, since it's running in a Linux VM; likewise for macOS binaries on macOS, Solaris on Solaris, etc.

Docker on WSL2 kind-of runs on the host, though.

WSL1 as far as I understand works like wine, transpiling calls to NT. But isn't WSL2 just a VM?

Can't read, cut off after first paragraph with "download app / sign up" marketing bullshit. Medium should be blocked from HN.

Yeah, makes Telegram's read mode useless.

Docker all the things!

Reply on news.ycombinator.com