Go is portable until you have to deploy on AS/400
Go is portable, until it isn't
51–60 of 138 posts
Re: Go is portable, until it isn't
#52Once you use CGO, portability is gone. Your binary is no longer staticly compiled. This can happen subtley without you knowing it. If you use a function in the standard library that happens to call into a CGO function, you are no longer static. This happens with things like os.UserHomeDir or some networking things like DNS lookups. You can "force" go to do static compiling by disabling CGO, but that means you can't u…
You don't need CGO for SQLite in most cases; I did a deep dive into it here.
https://til.andrew-quinn.me/posts/you-don-t-need-cgo-to-use-...
Re: Go is portable, until it isn't
#53Cgo is terrible, but if you just want some simple C calls from a library, you can use https://github.com/ebitengine/purego to generate the bindings.
It is a bit cursed, but works pretty well. I'm using it in my hardware-backed KMIP server to interface with PKCS11.
Re: Go is portable, until it isn't
#54And a set of people rediscovered why cross compiling only works up to certain extent, regardless of the marketing on the tin.
The point one needs to touch APIs that only exists on the target system, the fun starts, regardless of the programming language.
Go, Zig, whatever.
Re: Go is portable, until it isn't
#55And a set of people rediscovered why cross compiling only works up to certain extent, regardless of the marketing on the tin. The point one needs to touch APIs that only exists on the target system, the fun starts, regardless of the programming language. Go, Zig, whatever.
You're thinking of cross platform codebases. There's nothing about cross compilation that stops the toolchain from knowing what APIs are present & not present on a target system.
Re: Go is portable, until it isn't
#56And a set of people rediscovered why cross compiling only works up to certain extent, regardless of the marketing on the tin. The point one needs to touch APIs that only exists on the target system, the fun starts, regardless of the programming language. Go, Zig, whatever.
You're thinking of cross platform codebases. There's nothing about cross compilation that stops the toolchain from knowing what APIs are present & not present on a target system.
Cross compilation and cross platform are synonymous in compiled languages, in regards of many issues that one needs to care about.
Cross platform goes beyond in regards to UI, direction locations, user interactions,...
Yeah, if you happen to have systemd Linux libraries on macOS to facilitate cross compilation into a compatible GNU/Linux system than it works, that is how embedded development has worked for ages.
What doesn't work is pretending that isn't something to care about.
Re: Go is portable, until it isn't
#57Systemd. Binary logs are wonderful aren't they?
Re: Go is portable, until it isn't
#58There's no such thing as a portable application; only programs limited enough to be lucky not to conflict with the vagaries of different systems.
That said, in my personal experience, the most portable programs tend to be written in either Perl or Shell. The former has a crap-ton of portability documentation and design influence, and the latter is designed to work from 40 year old machines up to today's. You can learn a lot by studying old things.
Re: Go is portable, until it isn't
#59Go was never truly portable on Linux unfortunately due to its dependency on libc for DNS and user name resolution (because of PAM and other C-only API). Sure, pure Go implementation exists, but it doesn't cover all cases, so, in order to build a "good" binary for Linux you still needed to build the binary on (oldest supported) Linux distro.
If your production doesn't have any weird PAM or DNS then you can indeed just cross-compile everything and it works
Re: Go is portable, until it isn't
#60Well now you've gone and linked to a fascinating tool which I'm going to have to dive into and learn: https://kaitai.io/
Thanks.