12 ms·
If Golang decides to avoid the platform interface library, any resulting problems are on Golang. I totally get Go's "not C" ethos, but there's no incompatibilit
by quotemstr 8y ago
If Golang decides to avoid the platform interface library, any resulting problems are on Golang. I totally get Go's "not C" ethos, but there's no incompatibility between being not C and making system calls the way that programs are expected to make them on a platform. Go is flagrantly and needlessly incompatible with a lot of things, and there's no functionality or performance rationale for it.
There is absolutely nothing about the Go language or runtime environment that excuses them calling into libc to do platform things. Nothing. Every other managed language environment does it, and Go can too.
- int_19h 8y ago> Go is flagrantly and needlessly incompatible with a lot of things If you don't mind me asking, what are you thinking about, syscalls aside? The way they handle stack?
- johncolanduoni 8y agoThe big reason on Linux is libc symbol versioning. You can inadvertently link to newer versions of glibc symbols if you don’t build on a platform using the oldest libc you support. Go binaries have the advantage of being able to run on any Linux kernel they support, regardless of what distro and version they were built on. With Rust I usually end up having to compile a bunch of build-time dependencies from source on my build images because of this, instead of just using a version of Debian etc. new enough to have the right dependencies in the package repo. However I don’t think Go ‘s approach makes sense on some other platforms (e.g. macOS) that don’t suffer from this issue. In those cases you sacrifice forward compatibility for no real benefit.
- quotemstr 8y agoWith the right linker script, you too can link against whatever symbol versions you want regardless of host OS. That it's annoying to do so is a minor problem with linker interfaces, not a fundamental error in the normal program execution model.
- johncolanduoni 8y agoI’m not sure where I said it was an error, let alone a “fundamental error in the normal program execution model”. It’s quite annoying either way you try to solve it; I haven’t used a linker script because then I have to hunt down each symbol version anytime I link a new symbol from glibc, instead of the future-proof setting up of an ancient build image once. If you’re writing a language forcing you to let the language compiler handle all linking of images is not a particularly user-friendly solution.
- GordonS 8y agoYep, we have an ancient Ubuntu 7.04 build server for exactly this reason - linking against an old libc. This is how we've done it for something like 10 years now, and I've never thought about it since it works - but is there another approach we could use to link against an older libc version from a newer Ubuntu version?
- viraptor 8y agoDoes the old libc not compile on the new system anymore? You could install it on the side, link to it, and fix up paths if needed.
- loeg 8y agoTo be clear, I fully agree with all of that.
- j16sdiz 8y agoGolang use segmented stack for goroutines. Libc support is very poor for that.
- loeg 8y agoIt started that way, but moved to contiguous stacks in 1.3.
- ori_b 8y agoIf you need to keep the platform interface library, then the kernel needs to keep supporting it. If you can't break ABI or API, then you're merely shuffling the pain point, not solving it. The solution is to just tell people to update their code. Or accept that some bad APIs will be baked in for eternity, and deal with it.