[jgowdy]

Is the new tech lead more likely to get rid of the glibc-isms that Golang won't let go of, like crashing if non-ELF standard parameters like env aren't passed in ELF library initialization, or maybe supporting global-dynamic thread local storage so we can dlopen() shared objects made in Go on platforms that don't hack like glibc?

Go's obsession with glibc-isms is really unfortunate, and it's been many years. If you're using Go with containers on Alpine/musl, keep your code very vanilla, because they won't support you.

[liveoneggs]

golang's priority is "works inside of google" and everything else tends to be a bit of a fight

[rsc]

This is definitely not true. "Inside of Google" would have been just linux/amd64 for a very long time. Now it includes linux/arm64 too, but that port happened before Google needed it. And all the other ports are not used inside of Google, except maybe the Mac port if you count developers laptops.

[liveoneggs]

https://github.com/golang/go/issues/12914

[jgowdy]

Here are some citations since people seem to be just downvoting because they don't like the message:

Go requiring non-ELF standard parameters for initialization of supposedly "C ABI" libraries, open since 2015.

https://github.com/golang/go/issues/13492

The Go project specifically acknowledging the glibc-isms here:

"All Linux first class ports are for systems using glibc only. Linux systems using other C libraries are not fully supported and are not treated as first class."

https://go.dev/wiki/PortingPolicy

Go only supporting static-init thread local storage, and thus their "C ABI" libraries can only be dlopen()'ed if the libc pre-allocates memory to hack in libraries later.

https://github.com/golang/go/issues/54805

[rsc]

If you just want to run Go programs on Alpine, it works fine. (I put some effort in back in Go 1.21 to make sure that the downloaded binary toolchains for Linux even work fine on Alpine.)

If you want to use c-shared mode and dlopen, then yes that only works with glibc, but that mode barely works at all anyway. It's not actively supported at all.

[jgowdy]

Respectfully, these vague states of support between “active” and less active, “first class” and not first class, etc comes off as “we want to say we have that but shrug any time it’s deficient.”

Its similar to calling the port overall “linux/<cpu-arch>” rather than “linux/<libc>/<cpu-arch>” which wouldn’t normally be called for except when you’re going to embed a bunch of a particular libc specific behavior in your consumption of libc.

Listening to Go advocates talk about C interop like it’s not only a solved problem but quite literally a strength of Go, while Go project leaders represent that support quite differently isn’t it. Perhaps clarification of these level of support terms and how the project embraces glibc specific behaviors unapologetically would help.