so like every other language
Go is portable, until it isn't
91–100 of 138 posts
Re: Go is portable, until it isn't
#92Earlier quoted context omitted.
I was surprised too, that I had to check the docs, so I assume the user was misinformed.
Perhaps I misremembered or things changed? For instance, the os/user results in a dynamicly linked executable: https://play.golang.com/p/7QsmcjJI4H5 There are multiple standard library functions that do it.. I recall some in "net" and some in "os".
os.UserHomeDir is specified to read the HOME environment variable, so it doesn’t require CGo. os/user does, but only to support NSS and LDAP, which are provided by libc. That’s also why net requires CGo- for getaddrinfo using resolv.conf
Re: Go is portable, until it isn't
#93This 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.
Re: Go is portable, until it isn't
#94Was there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
It's generally less robust to run CLI tools and scrape the output. Usually it isn't intended to be machine readable, and you have to handle extra failure modes, like incompatible tool versions, missing tools, incorrect parsers, etc.
It's the lazy-but-bad solution.
Re: Go is portable, until it isn't
#95Earlier quoted context omitted.
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…
> Cross compilation and cross platform are synonymous in compiled languages
Err, no. Cross-platform means the code can be compiled natively on each platform. Cross-compilation is when you compile the binaries on one platform for a different platform.
Re: Go is portable, until it isn't
#96Hashicorp's Vault go binary is a whopping 512Mb beast. Recently considered using its agent mode to grab secrets for applications in containers but the size of the layer it adds is unviably big. And they don't seem interested into making a split server/client binary either...
[deleted]
Re: Go is portable, until it isn't
#97Was there not a third option: Calling the journalctl CLI as a child process and consume the parsed logs from the standard output? This might have avoided both the requirement to use CGO and also to write a custom parser. But I guess I am missing something.
It's generally less robust to run CLI tools and scrape the output. Usually it isn't intended to be machine readable, and you have to handle extra failure modes, like incompatible tool versions, missing tools, incorrect parsers, etc. It's the lazy-but-bad solution.
journalctl with -o export produces a binary interchange format. Would you rather have bugs or API rot from that, or in an internal tool?
Re: Go is portable, until it isn't
#98I ran into this issue when porting term.everything[0] from typescript to go. I had some c library dependencies that I did need to link, so I had to use cgo. My solution was to do the build process on alpine linux[1] and use static linking[2]. This way it statically links musl libc, which is much friendlier with static linking than glibc. Now, I have a static binary that runs in alpine, Debian, and even bare container…
> do the build process on alpine linux and […] statically link musl libc IIRC it used to be common to do builds on an old version of RHEL or CentOS and dynamically link an old version of glibc. Binaries would then work on newer systems because glibc is backwards compatible. Does anyone still use that approach?
If you need glibc for any kind of reason, that approach is still used. But that won’t save you if no glibc is available. And since the folks here want to produce a musl build anyways for alpine, the easier approach is to just go for musl all the way.
Re: Go is portable, until it isn't
#99So you can’t pull in c libraries built for different distributions and expect this to work.
If you use pure go, things are portable. The moment you use C API, that portability doesn’t exist. This should be apparent.
Re: Go is portable, until it isn't
#100Has nothing to do with go. You added a dependency which is not portable. It is well known that systemd project only targets Linux.
Vendorise systemd and compile only the journal parts, if they are portable and can be isolated from the rest. Otherwise just shell out to journalctl.