Live data from Hacker News

The simplicity of single-file Golang deployments

amazingcto.com

201–210 of 232 posts

Re: The simplicity of single-file Golang deployments

#201

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.

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great. I run a few Go apps, all are single executables, upgrading to new releases has never been easier. if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen.

And there's also "purego" as an implementation that directly generates shellcode.

Maybe those will help you, too?

I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.

[1] https://github.com/Binject/debug

[2] https://github.com/ebitengine/purego

Re: The simplicity of single-file Golang deployments

#202

Earlier quoted context omitted.

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great. I run a few Go apps, all are single executables, upgrading to new releases has never been easier. if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen. And there's also "purego" as an implementation that directly generates shellcode. Maybe those will help you, too? I am just mentioning these because for my use…

very useful,thanks

Re: The simplicity of single-file Golang deployments

#203
post #14

When I was stuck doing a web application in Java 15 years ago, I hated everything about it except for the deployment story, which boiled down to a single .war file being pushed to the server. When we upgraded to Perl, I liked that system so we designed deployment around "PAR" files in a similar way, bundling all of the dependencies together with the application in the CI build process, and I wrote a tiny bit of infra…

Excellent roast!

Re: The simplicity of single-file Golang deployments

#204
post #129

Earlier quoted context omitted.

Java never needed Docker, in fact the Docker / Kubernetes is now re-inventing Java Application Servers with WASM containers.

XML ruined Java.

Says the guy with a nickname from a language that has XML support on its type system.

Re: The simplicity of single-file Golang deployments

#205
post #107

Earlier quoted context omitted.

I remember those days well. It really meant you had to be careful with bugs and documentation. It is not clear to me that the we are winning with daily or multiple times daily release schedules at this point.

Were people careful with bugs and documentation? I remember the Internet blowing up one day because every Windows install was sending every IP on the Internet a virus, and there was nothing anyone could do about it. (And yes, Unix also had similar worms, though they largely predate me!) Word used to crash and corrupt your entire novel. There was no online banking. I'm not sure the rose-colored glasses are a realistic…

I ran a software company that predated the web. Yes, we were incredibly careful. When you ran the risk of having to send out updates on disks QC was a big thing.

Re: The simplicity of single-file Golang deployments

#206

Earlier quoted context omitted.

We also install the JRE separately, but each app is a single executable (by Java) jar, which stands up a jetty instance when run. We also add a yml for configuration. It's a much better packaging & deploy story than frontend code or python.

Java comes the closest of any of the languages to Go’s static binary.

.Net? You can cross-compile self-contained binary and just drop it on the server.

Re: The simplicity of single-file Golang deployments

#208

Earlier quoted context omitted.

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

> Go's existing enumerations

Go doesn't have enumerations. So the first difference would be that my enums would actually exist.

> implicit list structure which, while kind of neat, isn't really a property of enumerations

It absolutely is, or people wouldn't have been regularly writing enums like

    typedef enum {
        KindSimple,
        KindComplex,
        KindEmacs,
        Kind_NUM_VALUES
    } Kind;
which they do about half the time.

> likely lamenting that Go doesn't enforce compile-time value constraints

Yes, that's my complaint as well. Which is why that "not sure about legality" part in my example: you want to be able to enumerate the enum (duh), but with last_value_of_enum++ being illegal, writing for-loop with "With incrementing (used in loops almost exclusively) taken care of, the rest of arithmetics on enums is meaningless in general except maybe in case of subtraction (when you use enums as keys/indices for a fixed-sized array) which is why I allow it — but it produces an int, of course.

As for what should happen in Kind(42) example — perhaps it could work like type-assertions?

    k, err := Kind(42)
    if err != nil {
        return err
    }

Re: The simplicity of single-file Golang deployments

#209

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.

[flagged]

That attitude assumes that the go standard library is the global maximum for Getting Stuff Done, and because of backwards compatibility guarantees ensures that it’s difficult to innovate on.

I think having a small standard library is actually a good thing because it encourages exploration of the space of possibilities.

For example Go’s stdlib http.HandlerFunc sucks, people instead opt for leaving it behind entirely in favour of Gin or trying to work around it with bad patterns like interface smuggling.

Re: The simplicity of single-file Golang deployments

#210
post #93

I feel like i'm taking crazy pills (at a low dose) when i read this stuff. I deploy Java applications. In a runnable condition, they aren't a single file, but they aren't many - maybe a dozen jars plus some scripts. Our build process puts all that in a tarball. Deployment comprises copying the tarball to the server, then unpacking it [1]. That is one step more than deploying a single binary, but it's a trivial step,…

Without any prior knowledge you can run my little go program on your computer. Can that be said about your program with other people?

If you are distributing a tool to desktops, and not via a package manager, then i agree that the single binary is a genuine advantage. There are ways to get similar results with Java, packaging code and a JVM into a single file, but they aren't as simple.

But the original post we're discussing, and my comment on it, was about deploying to servers.

Post reply on HN