This article reminds me of the days before LLMs ruled the world, when the word "agent" was most commonly used in the DevOps area, representing the program that ran on a remote machine to execute dispatched jobs or send metrics. Now I wonder how many developers would look at "agent" and think of this meaning.

Cross-compiling doesn't work because you're not defining your dependencies correctly and relying on the existence of things like system libraries and libc. Use `zig cc` with Go which will let you compile against a stub Glibc, or go all the way and use a hermetic build system (you should do this always anyhow).

This is an (organizational) tooling problem, not a language problem - and is no less complicated when musl libc enters the discussion.

Well, that was pretty obvious that the portability is gone, especially when you start linking into systemd, even on the host system you have to link with the shared libs into systemd, you cannot link statically.

Cgo 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.

Basically everything is portable unless it isn't. Java - the same. We fly in abstractions unless you need to delete a file

Go is portable until you have to deploy on AS/400

There'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.

I really hate this type of blog. It pollutes the world with this attitude of “I messed up, how I have to frame the problem in a way, and write a blog that lets my ego stay intact”, which results in blogs like this showing in decision making process as “why you should not use go”. And mostly people never look past the title.

The fact is go is portable, it provides the ability to cross compile out of the box and reasonably executed on other platforms it supports. But in this case, a decision that had little to do with go, the desire to use c code, a non go project, with their go project made things harder.

These are not “just a set of constraints you only notice once you trip over them”, this is trivializing the mistake.

Entire blog can be simplified to the following.

We were ignorant, and then had to do a bunch of work because we were ignorant. It’s a common story in software. I don’t expect everybody to get it right the first time. But what we don’t need is sensational titled blogs full of fluff to try to reason readers out of concluding the obvious. Somebody in charge made decisions uninformed and as a result the project became more complicated and probably took longer.

The portability story for Go is awful. I've blogged about this before: https://blog.habets.se/2022/02/Go-programs-are-not-portable....

It's yet another example of Go authors just implementing the least-effort without even a slight thought to what it would mean down the line, creating a huge liability/debt forever in the language.