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

Re: The simplicity of single-file Golang deployments

#211

Post by randomdata » Thu, Mar 23, 2023, 12:16 PM UTC

Joker_vD wrote: post #208

randomdata wrote: post #188

Earlier quoted context omitted.

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

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

That's obviously not true. That's what the iota dance is for.

    type Kind int

    const (
        KindSimple Kind = iota
        KindComplex
        KindEmacs
        Kind_NUM_VALUES   
    )

Go doesn't have a literal enum keyword, if that's what you mean, but enumerations aren't defined by having a specific keyword or specific syntax. Enumerations are a more general concept, defined as a set of named constants. The above is functionally identical to your example in C, among a host of other languages.

> Yes, that's my complaint as well.

Fine, but that's not a property of enumerations. If one wants support for value constraints, surely one should ask for that and not for something the language has had since the beginning?

Re: The simplicity of single-file Golang deployments

#212

Post by golergka » Thu, Mar 23, 2023, 12:38 PM UTC

zer00eyz wrote: post #20

From the article: "Standing here it looks like Docker was invented to manage dependencies for Python, Javascript and Java. It looks strange from a platform that deploys as one single binary." Let me say the quiet part out loud: Docker is covering up the fact that we don't write deployable software any more. Go isn't perfect either. The author isn't dealing with assets (images anyone?). I think there is plenty of room…

> Docker is covering up the fact that we don't write deployable software any more.

We do. It's just software now is a container image, and Docker is a development tool like Make.

Re: The simplicity of single-file Golang deployments

#213

Post by cxr » Thu, Mar 23, 2023, 1:31 PM UTC

pjc50 wrote: post #35

masto wrote: 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…

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

> I kind of miss cgi-bin. If we're ever to get back to a place where random "power users" can knock up a quick server to meet some computing need they have, easy deployment has to be a big part of that. Can we make it as easy to deploy as to post on Instagram?

I'd be happy with a future that takes some cues from literate programming, where if you want to deploy some application, the way you do it is to upload a copy of the software manual/specification. This should be sufficient to "teach" the server how the application should behave.

It's tempting to say "Ah, sounds like super advanced ChatGPT-ops or something approaching real AGI", but what I have in mind is something decidedly less magical. It's more akin to the sort of thing that Rob Pike brought up in his "The Design of the Go Assembler" talk ("you have a machine readable description[...] why not read it with a machine?").

https://www.youtube.com/watch?v=KINIAgRpkDA>

Re: The simplicity of single-file Golang deployments

#214

Post by cxr » Thu, Mar 23, 2023, 1:57 PM UTC

lenkite wrote: post #117

Is this article from 2016? You can do all this with Java nowadays. I have observed a lot of folks on HN whose last knowledge about Java was from a decade plus ago pontificating about Java deficiencies that no longer exist today. Use the GraalVM native build tools https://graalvm.github.io/native-build-tools/latest/index.ht... . "Use Maven to Build a Native Executable from a Java Application" https://www.graalvm.org/2…

You, and any other non-Golang programmer, could visit the golang.org site, download the latest release, untar it, write a hello-world service, and run "go build". It will take about that many steps and about 5 minutes, and you'll have your single-file binary ready for deployment.

Can you compare doing the same thing with Java? How many more steps does it take, assuming that you don't already have a standard Java dev setup that's configured and ready-to-go on your machine? Now, let's let you put your thumb on the scale and assume that you do already the standard setup, but you want to pursue what this posts lays out and that you insist can be done with Java. How much more effort does it take just to go from "typical Java setup" to "setup that actually lets you do what this article describes"? If the answer is not zero but your position is still that there's nothing special here because "You can do all this with Java nowadays", then it's because you're not understanding what "here" and "this" actually are.

Re: The simplicity of single-file Golang deployments

#215

Post by Joker_vD » Thu, Mar 23, 2023, 1:59 PM UTC

randomdata wrote: post #211

Joker_vD wrote: post #208

Earlier quoted context omitted.

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

> Go doesn't have enumerations. So the first difference would be that my enums would actually exist. That's obviously not true. That's what the iota dance is for. type Kind int const ( KindSimple Kind = iota KindComplex KindEmacs Kind_NUM_VALUES ) Go doesn't have a literal enum keyword, if that's what you mean, but enumerations aren't defined by having a specific keyword or specific syntax. Enumerations are a more ge…

Mmm. The original comment asked for "Pascal-style enums". Those are different from C enums: they are incompatible with integers and other enums, they don't support arithmetic operations (you have to use succ()/pred() built-ins) and they contain precisely the named values (calling e.g. succ() one too many times is supposed to be a runtime-detected range error). Plus, enums being ordinal types, you could use them as array indices in type definitions, like "array[Kind] of real" (so effectively, enum range checks and array boundary checks implemented by the same mechanism).

So that's what I went with, because I actually liked Pascal-style enums but thought they could be somewhat improved, so what you've read is my ideas (Go is surprisingly close to Oberon and both lack enums).

Re: The simplicity of single-file Golang deployments

#216

Post by pjc50 » Thu, Mar 23, 2023, 2:09 PM UTC

cxr wrote: post #213

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…

> I kind of miss cgi-bin. If we're ever to get back to a place where random "power users" can knock up a quick server to meet some computing need they have, easy deployment has to be a big part of that. Can we make it as easy to deploy as to post on Instagram? I'd be happy with a future that takes some cues from literate programming, where if you want to deploy some application, the way you do it is to upload a copy…

> the way you do it is to upload a copy of the software manual/specification. This should be sufficient to "teach" the server how the application should behave.

i.e. a program.

I've actually worked with someone who had a system for compiling the "human readable" side of the h265 specification to executables. This he compared against the "reference implementation" provided in C. As a result he filed a large number of bugs against the standard for cases where the two differed in behavior.

Writing an unambiguous specification is hard work regardless of whether you do it in C or in English or something else, and it's what happens when the surprising cases arise that matters.

Re: The simplicity of single-file Golang deployments

#217

Post by caeril » Thu, Mar 23, 2023, 2:35 PM UTC

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.

This is generally only true with CGO_ENABLED=0.

I've found many times that a go binary, even if it has no cgo or cgo dependencies, will randomly require glibc on the target system to execute if you don't explicitly disable cgo in your build.

Re: The simplicity of single-file Golang deployments

#218

Post by pjc50 » Thu, Mar 23, 2023, 2:56 PM UTC

silisili wrote: post #189

brian_cunnie wrote: post #83

Earlier quoted context omitted.

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.

That's correct - and a system called "fastcgi" was built to give persistent execution and avoid startup time.

Re: The simplicity of single-file Golang deployments

#219

Post by randomdata » Thu, Mar 23, 2023, 2:57 PM UTC

Joker_vD wrote: post #215

randomdata wrote: post #211

Earlier quoted context omitted.

> Go doesn't have enumerations. So the first difference would be that my enums would actually exist. That's obviously not true. That's what the iota dance is for. type Kind int const ( KindSimple Kind = iota KindComplex KindEmacs Kind_NUM_VALUES ) Go doesn't have a literal enum keyword, if that's what you mean, but enumerations aren't defined by having a specific keyword or specific syntax. Enumerations are a more ge…

Mmm. The original comment asked for "Pascal-style enums". Those are different from C enums: they are incompatible with integers and other enums, they don't support arithmetic operations (you have to use succ()/pred() built-ins) and they contain precisely the named values (calling e.g. succ() one too many times is supposed to be a runtime-detected range error). Plus, enums being ordinal types, you could use them as ar…

The original comment asked for enumerations. Despite him not realizing, Go has those. It has a relatively unique syntax for defining enums, sure, but enumerations are not defined by specific syntax. They are a higher level concept that transcends any specific syntax implementation.

The original comment also hinted at wanting other features that some other languages have, including Pascal, although not stating which features specifically. I expect he was referring to wanting some kind of constraint system, which is the most common feature I hear requested of Go. But that's beyond the scope of enumerations.

Re: The simplicity of single-file Golang deployments

#220

Post by heleninboodler » Thu, Mar 23, 2023, 5:25 PM UTC

throwawaymaths wrote: post #180

cjdoc29 wrote: post #168

Earlier quoted context omitted.

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

No. Some bytecode compiled languages are compiled and require at least an archive to be unzipped or at least the virtual machine pre installed. Java is an example -- you'll want your your system java deployment to match the stuff stashed in your jar. Erlang is compiled but usually releases bundle the VM up with the project, so you typically deliver a full directory with the VM packed in there.

On top of this, with java, the jvm is itself dynamically linked to libc most of the time.