Live data from Hacker News

Go, Containers, and the Linux Scheduler

riverphillips.dev

141–143 of 143 posts

Re: Go, Containers, and the Linux Scheduler

#141
post #66

I still don't get the benefit of running Go binaries in containers. Totally get it for Rails, Python, etc, where the program needs a consistent set of supporting libraries. But Go doesn't need that. Especially now we can embed whole file systems into the actual binary. I've been looking at going in the other direction and using a Go binary with a unikernel; the machine just runs the binary and nothing else. I haven't…

As the author of Caddy, I have often wondered why people run it in containers. The feedback I keep hearing is basically workflow/ecosystem lock-in. Everything else uses containers, so the stuff that doesn't need containers needs them now, too.

We just gave this a go (pun intended) on Unikraft / kraft.cloud , Caddy runs fine on it!

Re: Go, Containers, and the Linux Scheduler

#142
post #119

Earlier quoted context omitted.

This goes against everything we've learned about effectively deploying and managing software at runtime. Using the golang binary as a packaging format for your app has the same energy as crafting it exclusively from impenetrable one-liners.

Sorry, I don't understand this. What's the difference between a Docker image made from a script and a Go binary made from a script?

The Docker image is more useful

Re: Go, Containers, and the Linux Scheduler

#143

Earlier quoted context omitted.

Sorry, I don't understand this. What's the difference between a Docker image made from a script and a Go binary made from a script?

The Docker image is more useful

I think we're back to square one here. Yes for other languages the Docker image is more useful, but for Go the image just contains a single binary file. It's just more bloat rather than more utility.
Post reply on HN