Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is portable, until it isn't

simpleobservability.com

Post reply on HN
Print view View original

101–110 of 138 posts

Re: Go is portable, until it isn't

#101

Post by mmulet »

imcritic wrote: post #75
mmulet wrote: post #9

I 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…

What troubles did you have with AppImages?

List of troubles:

[1]https://github.com/mmulet/term.everything/issues/28

[2]https://github.com/mmulet/term.everything/issues/18 (although this issue later gets sidetracked to a build issue)

[3]https://github.com/mmulet/term.everything/issues/14

[4]https://github.com/mmulet/term.everything/issues/7

Re: Go is portable, until it isn't

#102

Post by mbrock »

arianvanp wrote: post #85

FWIW I maintain an official implementation of the journal wire format in go now. https://github.com/systemd/slog-journal so you can at least log to the journal now without CGO But that's just the journal Wire format which is a lot simpler than the disk format. I think a journal disk format parser in go would be a neat addition

I've got a pure Go journald file writer that works to some extent—it doesn't split, compress, etc, but it produces journal files that journalctl/sdjournal can read, concurrently. Only stress tested by running a bunch of parallel integration tests, will most likely not maintain it seriously, total newbie garbage, etc, but may be of interest to someone. I haven't really seen any other working journald file writers.

https://github.com/lessrest/swash/tree/main/pkg/journalfile

Re: Go is portable, until it isn't

#104

Post by mmulet »

tasuki wrote: post #49
mmulet wrote: post #9

I 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…

Huh. Does term.everything just work, or are there some gotchas? This seems like it could be supremely useful!

It works so far! No major gotchas that I know of yet. From the perspective of the apps, they are just talking to a normal Wayland compositor, so everything works as expected. Just try it for your workflow, and if you run into any problems just open an issue and I’ll fix it.

Re: Go is portable, until it isn't

#105

Post by thomashabets2 »

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.

Re: Go is portable, until it isn't

#106

Post by pjmlp »

IshKebab wrote: post #95
pjmlp wrote: post #56

Earlier quoted context omitted.

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.

Not at all, cross platform means executing the same application in many platforms, regardless of the hardware and OS specific features of each platform.

Cross-compilation is useless if you don't actually get to executed the created binaries in the target platform.

Now, how do you intend to compile from GNU/Linux into z/OS, so that we can execute the generated binary out from the C compiler ingesting the code written in GNU/Linux platform, in the z/OS language environment inside an enclave, not configured in POSIX mode?

Using z/OS, if you're feeling more modern, it can be UWP sandboxed application with identity in Windows.

Re: Go is portable, until it isn't

#107

Post by mmulet »

johnisgood wrote: post #70
mmulet wrote: post #9

I 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…

I use `-ldflags '-extldflags "-static"` as well. From the .go file, you just do `// #cgo LDFLAGS: -L. -lfoo`. You definitely do not need Alpine Linux for this. I have done this on Arch Linux. I believe I did not even need musl libc for this, but I potentially could have used it. I did not think I was doing something revolutionary! In fact, let me show you a snippet of my build script: # Build the Go project with the…

I use alpine for this [1] reason, but I will admit that this is a premature-optimization. I haven’t actually ran into the problem myself.

——

Your code is great, I do basically the same thing (great minds think alike!). The only thing I want to add is that cgo supports pkg-config directly [2] via

  // #cgo pkg-config: $lib
So you don’t have to pass in linker flags manually. It’s incredibly convenient.

[1]https://stackoverflow.com/questions/57476533/why-is-statical...

[2]https://github.com/mmulet/term.everything/blob/def8c93a3db25...

Re: Go is portable, until it isn't

#108

Post by jeremyjh »

orochimaaru wrote: post #99

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

My assumption was that they were using a C API just from reading the headline. I don't use Go but these sorts of problems are common to any project doing that in just about any language.

Re: Go is portable, until it isn't

#109

Post by jeremyjh »

IshKebab wrote: post #94
combiBean wrote: post #84

Was 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 is designed for these use cases and has options to solve those issues. The lazy part here is you not doing any research about this tool before dismissing it as "not best practice", which is exactly what the fuckups who wrote this article did.
Post reply on HN