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

31–40 of 138 posts

Re: Go is portable, until it isn't

#31

Post by plufz »

cxr wrote: post #23
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 didn't see an explanation in the README that part of what the first GIF[1] shows is an effect created by video editing software (and not a screencapture that's just demonstrating the program actually running). "Screen images simulated" are the words usually chosen to start off the disclaimers in fine print shown at the bottom of the screen when similar effects appear in commercials. I think that it would make sense…

Why would an open source project need to have any disclaimer? They are not selling anything.

Re: Go is portable, until it isn't

#32

Post by nofriend »

plufz wrote: post #31
cxr wrote: post #23

Earlier quoted context omitted.

I didn't see an explanation in the README that part of what the first GIF[1] shows is an effect created by video editing software (and not a screencapture that's just demonstrating the program actually running). "Screen images simulated" are the words usually chosen to start off the disclaimers in fine print shown at the bottom of the screen when similar effects appear in commercials. I think that it would make sense…

Why would an open source project need to have any disclaimer? They are not selling anything.

Because lying is wrong even when open source projects do it.

Re: Go is portable, until it isn't

#33

Post by plufz »

nofriend wrote: post #32
plufz wrote: post #31

Earlier quoted context omitted.

Why would an open source project need to have any disclaimer? They are not selling anything.

Because lying is wrong even when open source projects do it.

I think it is a big stretch calling this visual effect lying.

I don’t know if it is a cultural American thing or just difference in interpretation but I had no difficulty understanding that this was a visual effect. But in my country ads don’t come with disclaimers. Do you feel like these disclaimers are truly helpful?

Re: Go is portable, until it isn't

#35

Post by hmans »

cxr wrote: post #23
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 didn't see an explanation in the README that part of what the first GIF[1] shows is an effect created by video editing software (and not a screencapture that's just demonstrating the program actually running). "Screen images simulated" are the words usually chosen to start off the disclaimers in fine print shown at the bottom of the screen when similar effects appear in commercials. I think that it would make sense…

[dead]

Re: Go is portable, until it isn't

#36

Post by jen20 »

From the article:

> In the observability world, if you're building an agent for metrics and logs, you're probably writing it in Go.

I'm pretty unconvinced that this is the case unless you happen to be on the CNCF train. Personally I'd write in Rust these days, C used to be very common too.

Re: Go is portable, until it isn't

#37

Post by nebezb »

cxr wrote: post #23
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 didn't see an explanation in the README that part of what the first GIF[1] shows is an effect created by video editing software (and not a screencapture that's just demonstrating the program actually running). "Screen images simulated" are the words usually chosen to start off the disclaimers in fine print shown at the bottom of the screen when similar effects appear in commercials. I think that it would make sense…

> “in commercials where such effects appear”

Good thing this isn’t a commercial then.

Re: Go is portable, until it isn't

#38

Post by cxr »

nofriend wrote: post #32
plufz wrote: post #31

Earlier quoted context omitted.

Why would an open source project need to have any disclaimer? They are not selling anything.

Because lying is wrong even when open source projects do it.

I don't feel that the person I responded to is lying or being intentionally deceptive.

Re: Go is portable, until it isn't

#39

Post by jchw »

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…

IMO this is the best approach, but it is worth noting that musl libc is not without its caveats. I'd say for most people it is best to tread carefully and make sure that differences between musl libc and glibc don't cause additional problems for the libraries you are linking to.

There is a decent list of known functional differences on the musl libc wiki:

https://wiki.musl-libc.org/functional-differences-from-glibc...

Overall, though, the vast majority of software works perfectly or near perfectly on musl libc, and that makes this a very compelling option indeed, especially since statically linking glibc is not supported and basically does not work. (And obviously, if you're already using library packages that are packaged for Alpine Linux in the first place, they will likely already have been tested on musl libc, and possibly even patched for better compatibility.)

Re: Go is portable, until it isn't

#40

Post by apitman »

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…

Note that you don't have to compile on an Alpine system to achieve this. These instructions should work on most distros:

https://www.arp242.net/static-go.html

Post reply on HN