The simplicity of single-file Golang deployments • Hacker News Board

Re: The simplicity of single-file Golang deployments

#101

Post by stanleydrew » Wed, Mar 22, 2023, 5:09 PM UTC

twic wrote: 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,…

Your footnotes basically invalidate your argument. You aren't just deploying a tarball, you also have to deploy the java runtime and make sure it's compatible with your application.

I agree that Go fans make too much of the single binary feature, but it does seem easier than your deployment process.

Of course your process is easy for you because you built it to fit your needs. But if you imagine a new developer who has no experience deploying either Java or Go applications, and consider what's easier to deploy without any previous knowledge or automation, I think you might agree the Go deployment options are simpler.

Re: The simplicity of single-file Golang deployments

#102

Post by smallerfish » Wed, Mar 22, 2023, 5:09 PM UTC

twic wrote: 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,…

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.

Re: The simplicity of single-file Golang deployments

#103

Post by 5e92cb50239222b » Wed, Mar 22, 2023, 5:11 PM UTC

simiones wrote: post #97

twic wrote: 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,…

Related to [1], I thought modern Java deployment style is to bundle the required modules of the JDK with your app, rather than any concept of a "deployed JDK". As it is, the difficulty of deploying a JDK + your app is much more than a single static binary, Go-style.

It depends on your requirements and environment. With most things I am working on the commands to deploy both look exactly the same:

  $ rsync -a foo server:/opt/foo
  $ rsync -a bar server:/opt/bar

Can you guess which one is a static binary written in Go, and which one is a directory with a slimmed down JRE produced by jlink + an application jar?

For those using containers, there's no practical difference between the two.

Re: The simplicity of single-file Golang deployments

#104

Post by ihateolives » Wed, Mar 22, 2023, 5:11 PM UTC

somehnguy wrote: post #36

marcosdumay wrote: post #25

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. When you distribute your software to other people, it cuts the step of installing the correct interpreter... at the cost of requiring the correct computer architecture. It is very likely a gain.

Exactly - I primarily write Java and fat-jars are great when developing apps for environments I control. But if I want to send an app to a friend it's a few additional steps to make sure they have the correct version of Java, paths are setup correct, etc. This isn't always trivial if they already have a different version of Java and want things to play nice side by side. Just bundle everything into a native executabl…

> But if I want to send an app to a friend it's a few additional steps to make sure they have the correct version of Java, paths are setup correct, etc

My friends would do full stop and reverse at "install Java" step. It will just not fly with 99% of people. It's not 1999 anymore.

Re: The simplicity of single-file Golang deployments

#105

Post by djbusby » Wed, Mar 22, 2023, 5:14 PM UTC

doodpants wrote: post #99

tomcam wrote: post #89

Earlier quoted context omitted.

Directly addressing the topic of a upvoted article is starting random language fights?

The article is about Go, and while the article mentions other languages for comparison, Rust is not one of them. So traceroute66's comment comes across as starting a Rust vs. Go fight where not appropriate.

Not even, they just expressing an opinion.

Re: The simplicity of single-file Golang deployments

#106

Post by Asdrubalini » Wed, Mar 22, 2023, 5:20 PM UTC

traceroute66 wrote: post #61

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.

[flagged]

Rust's philosophy (unlike Python's, for example) consists in not including tons of stuff in the standard library, this way you can choose the best implementation for your specific use case from one of the many crates (which are super easy to install, by the way). There is no "always the best" implementation for a specific functionality, nor a legacy-but-still-officially-supported-in-std implementation that nobody uses anymore but still needs to be maintained with its own namespace.

I don't see this as negative or "reinventing the wheel". Reinventing the wheel would be writing your own implementation, which doesn't happen if you can choose from many high-quality crates.

Re: The simplicity of single-file Golang deployments

#107

Post by tomcam » Wed, Mar 22, 2023, 5:22 PM UTC

zer00eyz wrote: post #31

ElevenLathe wrote: post #22

Earlier quoted context omitted.

Anymore? When were we writing "deployable" software in the past?

I'll bite! We used to ship software, on discs, and we didn't have the Internet to update it. There is plenty of software out there that works via your linux distress package manager. Note that this isn't everything you can get from your package manager. Plenty of things that are available are broken or miersable to get working unless you get the container/vm version.

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.

Re: The simplicity of single-file Golang deployments

#108

Post by solatic » Wed, Mar 22, 2023, 5:22 PM UTC

twic wrote: 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,…

> Deployment comprises copying the tarball to the server

You must not scale servers up and down very frequently then.

> both steps are done by a release script, so there is a single user-visible step... we do deploy the JDK separately

Wait, so it's not really a single user-visible step. You have one user-visible step to deploy the application server, and a different user-visible step to deploy the JDK.

Look, there's a reason why this way is old-fashioned. If you bought the server outright (i.e. running on-prem/colo), and so it represents a sunk cost, and the usage is all well within the ceiling of what that server is capable of providing, then sure, that's an eminently reasonable setup. If that server is humming along for several years, and electricity/data center costs are cheap, you're probably even saving money.

But in most cloud-first architectures, if you're not scaling down on low-usage times, you're wasting money. Scaling up and down is much, much simpler with immutable infrastructure patterns, and it's much simpler to just replace the entire image - whether that's a VM, or a container, or something else - rather than replacing just the application.

Re: The simplicity of single-file Golang deployments

#109

Post by Joker_vD » Wed, Mar 22, 2023, 5:22 PM UTC

pjmlp wrote: post #92

traceroute66 wrote: post #61

Earlier quoted context omitted.

[flagged]

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) // prints what you expect it to do
        }

        // not sure about legality or runtime behaviour of the followng
        var t = Kind.Emacs
        t++
        t = Kind(42)        
    }

Would be nice, not gonna lie.

Re: The simplicity of single-file Golang deployments

#110

Post by ardit33 » Wed, Mar 22, 2023, 5:32 PM UTC

twic wrote: 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,…

twic, you just made the op's point.

I too miss the days where you can just ssh/ftp a file, and boom, it was live. (this was usually a php file back then).

It is such a great feeling to be able to know whats going on at every step. With increased complexity, so has the deployment process in general. The java steps you described where the beginning of more complex deployments back then (1999-2001)

And, yes, I agree with the author in this case. Golang, makes it super simple to deploy a web service.