Hacker News Reader

Comment by krasin | Hacker News Reader

I agree with some of your points; but zero-reliance on libc is the reason why it's so easy to use Go in containers; and Docker is one of the primary reasons why Go is popular. It's what they have got right.

View on HN

You could statically link in libc and get the same effect.

Statically linking libc is it’s own minefield. It can and is done but even if you statically link everything else you should almost always dynamically link against your platform’s libc.

Statically linking libc is harder than dynamically linking it, but certainly easier than rewriting it.

Good thing we don't want to use much of libc functionality from Go, so nobody needs to reimplement all of it. It's not like people would be begging to call strcpy. All that's needed is the syscalls.

Statically linking a libc seems equivalent to statically linking Go's standard library, but with a whole lot less effort (on the part of the Go developers, that is).

Why? I see no reason you couldn’t on platforms with a stable syscall ABI, other than the standard reasons against static linking.

It depends on the libc.

glibc doesn't really "want" to be statically linked. It can be done sometimes, depending on how it's used, the phase of the moon and so on, but breaks from time to time until it's repaired.

Some of the issues are fundamental. For instance the dynamic linker is a part of the C libraries. If you statically link libc and then dynamically load another shared library, you can end up with two copies of the C libraries loaded at once.

The C library expects various external files to be found on disk, in a format that isn't totally forwards/backwards compatible. That's reasonable when things are dynamically linked because the linker and C library abstract the developer from format changes. If you statically link you should really statically link the data files too, but the C toolchain has no provision for that.

The ISO C standard library has no such expectations regarding external files.

Except glibc does not really support static linking of you want network support.

glibc is just one possible ISO C implementation with lots of extra stuff on top.

Says someone who has never actually tried to do that. You can statically link with Musl. But you can't really statically link with Glibc.

Technically speaking OP only suggested statically linking (a) libc, not glibc specifically, and musl is a libc.

Not sure what’s up with the combative tone? FWIW, I work as an operating systems developer. We sell several products incorporating a few in house libc variants. They are most certainly statically linked.

You can, it just might do some strange things when dealing with iconv.

You'd still have to get a static libc (not usually preinstalled), possibly compile it for a different os/architecture..

An issue here is that statically linking against glibc is generally regarded as a poor idea and I’ve seen a couple non trivial programs that refuse to run with other libc’s.

> Docker is one of the primary reasons why Go is popular.

Based on what data?

I've deployed all sorts of things which dynamically link libc in containers. This just isn't an issue in practice.

If you want static linking use musl..

You'd supposedly sacrifice performance though.

At least that's the common complaint for Alpine docker images... It's based on musl and halve of the community always complains about serious performance degradation

Well if the performance difference matters, going to a GC language makes no sense.

Tell that to the go enthusiasts. They're all claiming it to be peak performance surpassing everything else.

though even java is faster in most benchmarks

Except that Docker was originally written in Java by the former team that actually started the project, and nowadays contains modules written in OCaml taken from the MirageOS project, for the macOS and Windows variants of Docker.

So how much they got right regarding Docker's success and Go is a bit debatable.

Docker was not written in Java. It was shell scripts, python, then go. Dotcloud was primarily a python shop.

Perhaps you are thinking of a different project?

Probably Kubernetes which was indeed Java in formative years.

Kubernetes was never publicly available (open source) in any other language than Go. Early internal prototypes may have been in Java, but those bear no more resemblance to current Kubernetes than Borg does.

You are right, I got that wrong, too late to edit now.

Kubernetes was never Java.

Found the link about its origins.

https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

Unless she's talking about an internal prototype that never saw a public repository, Kris is wrong.

The original prototype that saw a public repo was written by Joe and Craig in Python (mostly Craig IIRC) and lasted for all of about a week before they switched to Go.

The original crew of contributors, all from Google, came from a Java background and definitely wrote Java-flavored Go, but no version of Kubernetes was ever written in Java.

Source: I know all the principals and was a contributing member when Kubernetes was initially released.

Yup, watching that talk at last years FOSDEM is what informed me of that part of the history also. Great talk, too!

Indeed, I got that wrong.

I think the parent was reffering to using Go in Docker containers, not using Go for implementing Docker itself.

That said, I agree that Docker was the first major project written in Go many people were exposed to and probably had some influence.

I'm just wondering, how is your line about the code taken from the MirageOS project relevant? Nobody uses the Windows and macOS variants of Docker in production.

Windows shops do use Docker in production, there are plenty of them.

It is relevant in the sense that Docker isn't 100% Go nowadays.

As an aside, do they use Windows containers in that context? Otherwise why?

Yes, for example in Azure deployments.

Reply on news.ycombinator.com