Live data from Hacker News

Go is portable, until it isn't

simpleobservability.com

131–138 of 138 posts

Re: Go is portable, until it isn't

#131

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.

You expect Go to magically make systemd journaling exist in macOS?

I can't even begin to comprehend the thought process here.

Re: Go is portable, until it isn't

#132
post #131

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.

You expect Go to magically make systemd journaling exist in macOS? I can't even begin to comprehend the thought process here.

I can't even begin to comprehend how you got from here to there.

I encourage you to elaborate on how you think that's connected, and not make a strawman argument. You may have not done so deliberately, but if you can't begin to comprehend that I would mean what you said, then you could give me the benefit of doubt and maybe entertain the idea that I did not.

Edit: In my blog post I give the example of getpwnam_r. One should not check for if the OS is Solaris in a given version range, but if getpwnam_r is one or the other type.

Re: Go is portable, until it isn't

#133
post #89
post #68

Earlier quoted context omitted.

> and even bare containers. Strange, i thought the whole point of containers was to solve this problem.

Depends how much you care about the size and security footprint of your container images.

Static linking doesn't solve security issues either.

Re: Go is portable, until it isn't

#134
post #131

Earlier quoted context omitted.

You expect Go to magically make systemd journaling exist in macOS? I can't even begin to comprehend the thought process here.

I can't even begin to comprehend how you got from here to there. I encourage you to elaborate on how you think that's connected, and not make a strawman argument. You may have not done so deliberately, but if you can't begin to comprehend that I would mean what you said, then you could give me the benefit of doubt and maybe entertain the idea that I did not. Edit: In my blog post I give the example of getpwnam_r. One…

No language is going to do that for you. And I don't think Go promissed otherwise.

Perhaps it's about managing expectations.

Re: Go is portable, until it isn't

#135
post #134

Earlier quoted context omitted.

I can't even begin to comprehend how you got from here to there. I encourage you to elaborate on how you think that's connected, and not make a strawman argument. You may have not done so deliberately, but if you can't begin to comprehend that I would mean what you said, then you could give me the benefit of doubt and maybe entertain the idea that I did not. Edit: In my blog post I give the example of getpwnam_r. One…

No language is going to do that for you. And I don't think Go promissed otherwise. Perhaps it's about managing expectations.

I mean… my whole blog post is about how autotools does that easily, and Go does not.

"Language", no. But Go's build comments are not really part of the language proper.

Re: Go is portable, until it isn't

#136
post #69

Earlier quoted context omitted.

It only works in a dynamically-linked binary, because the dynamic linker needs to be loaded.

That makes sense. Some digging turns up some workarounds; the best I found was https://github.com/jart/cosmopolitan/releases/tag/3.1

You can write your own dynamic loader, or port the one from libc, or attempt to statically link it (against its wishes). Nothing stops you opening a .so file and mmapping the appropriate sections - that's what the dynamic loader does, and it's just normal user-space code, after all. However, the libc dynamic loader definitely prefers to be your program's entry point. You're swimming against the current by doing it any other way.

Re: Go is portable, until it isn't

#137
post #133
post #89

Earlier quoted context omitted.

Depends how much you care about the size and security footprint of your container images.

Static linking doesn't solve security issues either.

Static linking can be a layer of defence against some security issues, depending on your circumstances.

But what I said was "reduced security footprint", considering the trade offs between a single statically linked binary and a full (or even cut down) Linux distribution.

Re: Go is portable, until it isn't

#138
post #107

Earlier quoted context omitted.

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://stacko…

Thanks! I did not use pkg-config because the compiled .c is the one I have written specifically for this Go program. :D I did it all on my own system as well (Void Linux).
Post reply on HN