Comment by hsn915 | Hacker News Reader

Comment by hsn915 | Hacker News Reader

I'm in a similar boat. I hate Docker. I haven't used it myself but seen it used at various companies, and to me as a programmer, it's a nightmare.

Docker "solves" the problem of Linux system configuration, but the solution it provides is literally the equivalent of "shove it under the rug". It doesn't solve the problem; it just attemps to hide it.

The way I solve the problem is by eliminating it; by making programs that don't require any system configuration.

Most people like to program in an interpreted language and use a separate engine to store and manage the data. The language runtime only has a "debug" server, so you need a separate http server and you need to configure it so that it can execute scripts written in your favorite language.

So this means the system/environment needs to be setup so that 1) an http server is installed and configured 2) the specific version of the interpreter is installed on the system 3) the database engine is setup and configured. I wish it stops here, but it gets much worse.

So what I do instead is use libraries for all the above. I use a compiled language. The http server is a library. The database engine is a library. Therefore, nothing needs to be configured in the environment. Just upload the binary and run it.

I think you're confusing some things. First of all, "just uploading" the binary only works in languages with a very lazy approach to modularization, aka static linking. But thinking that uploading binaries "works" is a fallacy in itself. Just look at the binaries you're producing, they probably have at least a couple of dynamically linked dependencies.

Second, interpreted languages could work in exactly the same way. I am not sure, but I think there are tools in Javascript land that gobble all dependencies together into one script. But even with python or lisp, you could easily copy the whole folder (venv in Python lingo) around. If you need to, just add an interpreter as well.

Finally, even Docker doesn't guarantee you perfect portability. Every application you code also has an implicit dependency on the kernel ABI. It's just that Linus et. al. do a really good job at avoiding ABI breakage. That's why you so often succeed in copying binary code around.

> very lazy approach to modularization, aka static linking

Static linking is the only right approach.

"I'm in a similar boat. I hate Docker. I haven't used it myself..."

Different brushes for different strokes but I'm curious to know how you can hate something without having tried it? This might be understandable for something like sexuality or even types of video games, but containerisation, .devcontainers and the like. How can you hate something without trying it?

Docker doesn't shove anything under the rug and hide it in my experience, instead it surfaces reproducibility in your face and encourages you to deal with it.

What's the alternative for compilable languages short of makefiles? Even then you can't guarantee it will work on your colleagues Linux and MacOS workstations (let's ignore Windows) but that's where docker and .devcontainer shine.

> I'm curious to know how you can hate something without having tried it?

Had to deal with it at work

> Therefore, nothing needs to be configured in the environment. Just upload the binary and run it.

I have a project right now that works with pdf files. I need specific packages and resources install for this to work. I need this not only on my dev machine, but also in my serverless prod environment. I dev in Windows, but deploy to Linux.

How would you solve this by just using a single binary?

I do what I said in my last sentence:

> what I do instead is use libraries

Reply on news.ycombinator.com