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

The simplicity of single-file Golang deployments

amazingcto.com

Post reply on HN
Print view View original

181–190 of 232 posts

Re: The simplicity of single-file Golang deployments

#181

Post by lmm »

xyzzy4747 wrote: post #77
galdor wrote: post #28

Earlier quoted context omitted.

I'm unsatisfied with the current situation too, but it's a hard problem. You can either go full container (which means no BSD, and having to deal with Docker or Kubernetes and all the associated woes), or fallback to native packages which are a huge PITA to build, deploy and use. I think that Nix and Guix have part of the solution: have a way to build fully independent packages that can be easily installed. But I'm n…

Just curious, what’s the benefit of using FreeBSD versus Debian/Ubuntu?

Not the person you replied to, but it tends to be more stable (commands and interfaces change less) and have better backwards compatibility; also ZFS is better-integrated than on Linux and better than any of the other options on Linux. (Jails used to be another advantage, but these days linux containers can more or less do most of the same things)

Re: The simplicity of single-file Golang deployments

#182

Post by superb-owl »

lagniappe wrote: post #120
quaintdev wrote: post #57

Earlier quoted context omitted.

> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.

I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now. Just do `release --name "mycoolprogram" --version "0.1.0"` and it will output all of your labeled release binaries for every platform your code supports. check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sport…

looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.

Re: The simplicity of single-file Golang deployments

#183

Post by nu11ptr »

cjdoc29 wrote: post #168
quaintdev wrote: post #57

Earlier quoted context omitted.

> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.

So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?

Golang is special because pure Go programs tend to have a closed ecosystem with its own linker (that typically don't link to libc or other C libs) so it makes static linking very easy. Other languages can certainly do static linking, but it tends to be a bit challenging to set it up on different OS's due to the need to have all needed C libs as static libs and then instruct the linker appropriately.

Re: The simplicity of single-file Golang deployments

#184

Post by lagniappe »

superb-owl wrote: post #182
lagniappe wrote: post #120

Earlier quoted context omitted.

I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now. Just do `release --name "mycoolprogram" --version "0.1.0"` and it will output all of your labeled release binaries for every platform your code supports. check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sport…

looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.

Thanks for checking it out :) I'm not going to pretend I haven't been refreshing the page waiting for bugs and comments

Re: The simplicity of single-file Golang deployments

#185

Post by initplus »

nightfly wrote: post #137
taeric wrote: post #84

Earlier quoted context omitted.

Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :( The docker world is a neat example of this. The stories of ${absurdly high per…

The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library

The solution to this is to make the build process as simple as possible. Then pushing updates has a much lower maintenance cost.

I can be confident I will be able to build >90% of go programs by cloning the repo and calling go build.

Re: The simplicity of single-file Golang deployments

#186

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #150
drewg123 wrote: post #34

The fact that it produces a single static binary is one of the nicest things about golang. This used to be easy with C (on BSD & Linux) a long time ago, but then everything started to depend on various shared libs, who then depend on other libs, then things started to even dlopen libs behind your back so they didn't even show up in ldd, etc. Sigh.

IME, using musl, compiling static binaries written in C is as easy as it was before glibc changes and as it has always has been on NetBSD. I compile static binaries written in C every day on Linux. I never encountered any problems compiling static binaries on BSD.

Many of the static binaries I use rely on dependencies other than libc. Most are small programs. Out of personal preference, I generally try to avoid large programs with numerous dependencies. Exception might be something like ffmpeg. Static binary for the author is 21M but package from repository is 84M so the static binary uses less space. ffmpeg has many dependencies besides libc.

Re: The simplicity of single-file Golang deployments

#187

Post by mftb »

cytzol wrote: post #113
joncfoo wrote: post #29

Earlier quoted context omitted.

Assets of any kind can be embedded in the executable and accessed via the embed.FS interface. This makes it trivial to bundle up all dependencies if desired.

Embedding your assets like this isn't always an improvement. For example, I work on a site with a Go server and static content pages, and I like that I can update one of the pages and see the change instantly without having to re-compile the entire server binary just to get the new files included.

Easy enough to have the app check the regular file system first, then fallback to the embedded fs. You could have the best of both worlds.

Re: The simplicity of single-file Golang deployments

#188

Post by randomdata »

Joker_vD wrote: post #109
pjmlp wrote: post #92

Earlier quoted context omitted.

If only they would decide what to do with plugin package, not use SCM paths for packages and decide to eventually support enumerations instead of iota dance (Pascal style would be enough. Maybe 10 more years.

type Kind enum { Simple, Complex, Emacs, } const kindStrings [Kind]string = { "simple", "complex", "emacs", } func (k Kind) String() string { return kindStrings[k] } func t() { var a = Kind.Emacs - Kind.Simple // a has type int and value 2 var b = Kind.Simple + Kind.Emacs // type error var c = Kind.Simple + 1 // type error var d = len(Kind) // d has type int and value 3 for k := range Kind { fmt.Printf("%v\n", k) //…

How is this any different than Go's existing enumerations, aside from the enumeration also creating an implicit list structure which, while kind of neat, isn't really a property of enumerations.

The parent is likely lamenting that Go doesn't enforce compile-time value constraints on enumerated sets like some languages do, but many other languages don't ether. Not even Typescript does. If Typescript doesn't find it important to have such value constraints, Go most certainly never will.

Re: The simplicity of single-file Golang deployments

#189

Post by silisili »

brian_cunnie wrote: post #83
pjc50 wrote: post #35

Earlier quoted context omitted.

> I don't see what's special or better about compiling everything into a single binary, apart from fetishizing the executable format. Indeed. If you think of the docker image itself as an executable format like PE or ELF, this becomes clearer. Rather than targeting the OS API, which has completely the wrong set of security abstractions because it's built around "users", it defines a new API layer. > "I can deploy by…

AWS Lambda is basically cgi-bin. Except, of course, they re-branded it as an exciting new technology, which I think was a clever move on their part.

Correct me if im wrong, but cgi-bin things executed from scratch each time IIRC.

Whereas lambda will stay running for a period of receiving requests.

Re: The simplicity of single-file Golang deployments

#190

Post by heleninboodler »

cjdoc29 wrote: post #168
quaintdev wrote: post #57

Earlier quoted context omitted.

> The fact that it produces a single static binary is one of the nicest things about golang. Not only that it can also cross compile for different architecture and operating systems.

So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?

Not dynamically linking to libc is pretty unusual. The libc-equivalent parts are in the Go runtime, statically linked.
Post reply on HN