4 ms·

> decent performance Also in Java (if not better there). > single binary deployment Also possible in Java > straightforward compilation from source ditto

by apta 10y ago

> decent performance Also in Java (if not better there). > single binary deployment Also possible in Java > straightforward compilation from source ditto > easy to contribute to ditto Edit: a much more expanded reply here: https://news.ycombinator.com/reply?id=13451098&goto=item%3Fid%3D13449728%2313451098 https://news.ycombinator.com/reply?id=13451098&goto=item%3Fi...

devoply 10y ago
> single binary deployment > Also possible in Java Does not mean that's the default. Default matters quite a bit. Not to mention the verbosity of Java that I guess you can use other languages on top of Java to deal with. But Go makes a lot of sense for these sorts of projects which in the past would be written in C or C++
- apta 10y ago
  Funnily enough, there are complaints about Go being verbose. Just look at the error handling discussion that was on here a few days ago.
closeparen 10y ago
>Also possible in Java Really? When working with Java system-level tools I always need a shell script to manage JAVA_HOME and CLASSPATH, or an OS package where the maintainer has done that for me. I've seen these generated, but in a way that places an artificial upper bound on the number of command line arguments. Some programs like to have tons of these, so only going up to $10 doesn't cut it. With Go I can literally just copy the binary over and execute it.
- pjmlp 10y ago
  There are quite a few AOT native compilers available for Java, actually all commercial JDK ones.
weberc2 10y ago
Yeah, Go and Java have comparable deployment. In practice, Java doesn't have single binary deployments; it has fat jars, which is similar, but the client must still have a Java runtime installed to run them. More importantly, you can't bank on every Java project supporting this out of the box. Java also doesn't have straightforward compilation; with Go, it's `go build` for nearly every project; no metadata files or build scripts. For Java, you must learn Maven, Ant, Gradle, etc just to get off the ground. I actually like Java, but I wouldn't say it's as easy or convenient as Go on the counts mentioned above. YMMV.
- vorg 10y ago
  Go doesn't have single binary deployments either. You need a separate binary for every target platform. Java's use of a VM was intended to get around this restriction so that a single jar file would work on any platform, as long as the JVM and libraries were present. Though 20 years ago people would call it "write once, debug everywhere" but perhaps that's not much of a problem anymore.
  - weberc2 10y ago
    > Go doesn't have single binary deployments either. You need a separate binary for every target platform. You're confusing static compilation and portability. Static compilation produces a single binary artifact that can run on the platform for which it was compiled. This doesn't imply that it will run on every (or even any) other platforms--in fact, it's not possible for a single binary to run on every platform.

by apta 10y ago

devoply 10y ago

> single binary deployment > Also possible in Java Does not mean that's the default. Default matters quite a bit. Not to mention the verbosity of Java that I guess you can use other languages on top of Java to deal with. But Go makes a lot of sense for these sorts of projects which in the past would be written in C or C++

apta 10y ago
Funnily enough, there are complaints about Go being verbose. Just look at the error handling discussion that was on here a few days ago.

closeparen 10y ago

>Also possible in Java Really? When working with Java system-level tools I always need a shell script to manage JAVA_HOME and CLASSPATH, or an OS package where the maintainer has done that for me. I've seen these generated, but in a way that places an artificial upper bound on the number of command line arguments. Some programs like to have tons of these, so only going up to $10 doesn't cut it. With Go I can literally just copy the binary over and execute it.

pjmlp 10y ago
There are quite a few AOT native compilers available for Java, actually all commercial JDK ones.

weberc2 10y ago

Yeah, Go and Java have comparable deployment. In practice, Java doesn't have single binary deployments; it has fat jars, which is similar, but the client must still have a Java runtime installed to run them. More importantly, you can't bank on every Java project supporting this out of the box. Java also doesn't have straightforward compilation; with Go, it's `go build` for nearly every project; no metadata files or build scripts. For Java, you must learn Maven, Ant, Gradle, etc just to get off the ground. I actually like Java, but I wouldn't say it's as easy or convenient as Go on the counts mentioned above. YMMV.

vorg 10y ago
Go doesn't have single binary deployments either. You need a separate binary for every target platform. Java's use of a VM was intended to get around this restriction so that a single jar file would work on any platform, as long as the JVM and libraries were present. Though 20 years ago people would call it "write once, debug everywhere" but perhaps that's not much of a problem anymore.
- weberc2 10y ago
  > Go doesn't have single binary deployments either. You need a separate binary for every target platform. You're confusing static compilation and portability. Static compilation produces a single binary artifact that can run on the platform for which it was compiled. This doesn't imply that it will run on every (or even any) other platforms--in fact, it's not possible for a single binary to run on every platform.