9 ms·

"1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual

by eweise 4y ago

"1) compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments." Docker makes deploying Java about the same as Go

klodolph 4y ago
Every Java app I've ever deployed, I needed to tune the JVM. Well, not when I'm running something locally. Every app I've deployed professionally in corporate environments (which is most of my experience running Java), I needed to tune the JVM.
- eweise 4y ago
  I'm surprised. Latest JVM versions are tuned really well out of the box. Tuning is a good thing by the way. Its the reason Java can handle areas that Go can't.
  - klodolph 4y ago
    Yeah, although it seems to be taking a while for everyone to update to the latest and greatest JVM versions.
- pjmlp 4y ago
  While in Go it gets rewritten in Rust instead, because it lacks the tuning knobs.
coldtea 4y ago
A.k.a.: Why just have a single thing (a statically compiled binary), when you can have several moving pieces and different levels of infrastructure and configuration to worry about (the hypervisor, the container runtime, the container cli, the open ports and shared volumes configuration, the host OS image, the JVM inside the image, java memory and gc tuning, and so on)
- eweise 4y ago
  Maybe you are building a standalone utility in Go that can be downloaded as a single binary. Great. Most places I work at, deploy to Kubernetes as docker containers
  - coldtea 4y ago
    Given that the context on this subthread is how a benefit from Go is that it "compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments." I fail to see how this information about "most places you work for" is relevant. Even if that's the case, you can always also deploy Go with kubernetes and whatever. But you can't deploy most of the others as a single static binary. (Getting one out of Java, for one, requires some half-arsed non-really-supported solutions, whereas getting one out of Go is the default).
    - eweise 4y ago
      "I fail to see how this information about "most places you work for" is relevant." I can spell it out. Where is I work is a web based business and those businesses are typically using hosted environments. Go binaries aren't an advantage in these environments.
      - coldtea 4y ago
        One can, and many do, just deploy a single Go binary into those "hosted environments". There have been a couple of posts on HN of teams doing that. In fact one can even do it your way, and use kubernetes and co in those hosted environments and Go binaries would still be an advantage -- because the container for the go-based service can just have a static binary inside, and be relatively easier to manage than a Java one.
        eweise 4y ago
        Java deploys as a single file so would be the same as a Go binary. Container just needs the JVM included, which is trivial.
tsimionescu 4y ago
Except a Java container running a simple REST server is going to be a few hundred megs, while a similar Go container will be around 10 megs most likely. Which doesn't matter all that much until you're distributing an app made out of 10-20 such services...
- pjmlp 4y ago
  Since Java 9 one can tier it down with jlink, previously the uberjar plugin could also be used for similar purposes.
  - tsimionescu 4y ago
    That's only true if your project and all your dependencies are modularized, right? I moved on to Go around the time Java 9 had recently come out, so no idea how well the ecosystem has evolved in this direction in the meantime. For the record, I miss many aspects of Java, especially the language and tooling, but Go was definitely the right choice for our project at the time. From what I've seen major Java projects are still delivered in large containers with a full JVM (ElasticSearch, Keycloak at least).
    - pjmlp 4y ago
      Not with the uberjar approach. Many projects choose the easy way out when packing their deliveries, and to certain extent Java is having a Python 3 moment with anything past Java 8. The cynic in me sees that as the main reason why Docker was adopted, HP-UX was already having containers in 1999 and no one was rushing to package Perl into them.

by eweise 4y ago

klodolph 4y ago

Every Java app I've ever deployed, I needed to tune the JVM. Well, not when I'm running something locally. Every app I've deployed professionally in corporate environments (which is most of my experience running Java), I needed to tune the JVM.

eweise 4y ago
I'm surprised. Latest JVM versions are tuned really well out of the box. Tuning is a good thing by the way. Its the reason Java can handle areas that Go can't.
- klodolph 4y ago
  Yeah, although it seems to be taking a while for everyone to update to the latest and greatest JVM versions.
pjmlp 4y ago
While in Go it gets rewritten in Rust instead, because it lacks the tuning knobs.

coldtea 4y ago

A.k.a.: Why just have a single thing (a statically compiled binary), when you can have several moving pieces and different levels of infrastructure and configuration to worry about (the hypervisor, the container runtime, the container cli, the open ports and shared volumes configuration, the host OS image, the JVM inside the image, java memory and gc tuning, and so on)

eweise 4y ago
Maybe you are building a standalone utility in Go that can be downloaded as a single binary. Great. Most places I work at, deploy to Kubernetes as docker containers
- coldtea 4y ago
  Given that the context on this subthread is how a benefit from Go is that it "compiles to a single executable that's easy to deploy. This is a compelling advantage over Java,C#,Python,Ruby that require runtimes or complicated virtual environments." I fail to see how this information about "most places you work for" is relevant. Even if that's the case, you can always also deploy Go with kubernetes and whatever. But you can't deploy most of the others as a single static binary. (Getting one out of Java, for one, requires some half-arsed non-really-supported solutions, whereas getting one out of Go is the default).
  - eweise 4y ago
    "I fail to see how this information about "most places you work for" is relevant." I can spell it out. Where is I work is a web based business and those businesses are typically using hosted environments. Go binaries aren't an advantage in these environments.
    - coldtea 4y ago
      One can, and many do, just deploy a single Go binary into those "hosted environments". There have been a couple of posts on HN of teams doing that. In fact one can even do it your way, and use kubernetes and co in those hosted environments and Go binaries would still be an advantage -- because the container for the go-based service can just have a static binary inside, and be relatively easier to manage than a Java one.
      - eweise 4y ago
        Java deploys as a single file so would be the same as a Go binary. Container just needs the JVM included, which is trivial.

tsimionescu 4y ago

Except a Java container running a simple REST server is going to be a few hundred megs, while a similar Go container will be around 10 megs most likely. Which doesn't matter all that much until you're distributing an app made out of 10-20 such services...

pjmlp 4y ago
Since Java 9 one can tier it down with jlink, previously the uberjar plugin could also be used for similar purposes.
- tsimionescu 4y ago
  That's only true if your project and all your dependencies are modularized, right? I moved on to Go around the time Java 9 had recently come out, so no idea how well the ecosystem has evolved in this direction in the meantime. For the record, I miss many aspects of Java, especially the language and tooling, but Go was definitely the right choice for our project at the time. From what I've seen major Java projects are still delivered in large containers with a full JVM (ElasticSearch, Keycloak at least).
  - pjmlp 4y ago
    Not with the uberjar approach. Many projects choose the easy way out when packing their deliveries, and to certain extent Java is having a Python 3 moment with anything past Java 8. The cynic in me sees that as the main reason why Docker was adopted, HP-UX was already having containers in 1999 and no one was rushing to package Perl into them.