4 ms·

Speaking as someone who writes go code every day right now, I like the language for a number of reasons, including the fact that it can be compiled and deployed

Speaking as someone who writes go code every day right now, I like the language for a number of reasons, including the fact that it can be compiled and deployed without anything like the sort of build/deploy insanity that a modern java installation comes with. So, I'd rather hit my head against the wall on GC problems while smart people improve it than hit my head against the wall with a MASSIVE deploy/build headache that definitely won't go away for a bunch of technical, political and historical reasons.

zak_mc_kracken 12y ago
> Speaking as someone who writes go code every day right now, I like the language for a number of reasons, including the fact that it can be compiled and deployed without anything like the sort of build/deploy insanity that a modern java installation comes with. Once properly set up, deploying Java is usually a one click affair, not sure what insanity you are talking about. Also, Go is compiled natively which certainly complicates the deployment mode (and expect more complications down the line once Go supports dynamic loading). Either way, Go's deployment model doesn't have much to do with the language and it will become more complex if the language becomes more popular.
mike_hearn 12y ago
What kind of insanity? Are you talking about desktop or server apps? Whichever you mean, you can create apps that have self contained JREs with the javapackager tool. But most server setups don't seem to need it. If you have a broken IT environment where your admins refuse to upgrade the JVM, that can be an issue, but then you might find yourself being told to stick with an obsolete version of Go in future too in such an environment.
- vessenes 12y ago
  Hi Mike! Fancy seeing you here. I'm not trying to start a religious conversation; so with that caveat, I'll respond -- By insanity, I'm referring to the need to grok stuff like this page: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html http://maven.apache.org/guides/introduction/introduction-to-... Building a large java application is not something I'm an expert at, but I have spent many hours of my life fighting with maven and ant and dependencies, happily some time ago. By comparison, there's "go build". Or if you need auto-cross-compiling, there's goxc. While an IT manager might limit the version of go on a server, it would have no impact on most go developers; I can build a self-contained binary for linux right from my Macbook Air in under 2 seconds with a single command. Or using goxc, I can build for all binary targets in very short order. To me reducing this sort of cognitive load on build/deployment is a HUGE benefit go provides, especially to junior developers or teams with different backgrounds.
  - zak_mc_kracken 12y ago
    You are confusing building and deploying. Building in Java is also a one line command. Deploying is also often a one line command (or a one click affair). The fact that Go is natively compiled makes this kind of deployment a bit more problematic, and it's bound to get more complicated once Go supports dynamic loading. I'm not trying to make a judgment call between Java and Go here, just pointing out that saying that one of these language is insanely more complicated to deploy than the other doesn't make much sense.

zak_mc_kracken 12y ago

> Speaking as someone who writes go code every day right now, I like the language for a number of reasons, including the fact that it can be compiled and deployed without anything like the sort of build/deploy insanity that a modern java installation comes with. Once properly set up, deploying Java is usually a one click affair, not sure what insanity you are talking about. Also, Go is compiled natively which certainly complicates the deployment mode (and expect more complications down the line once Go supports dynamic loading). Either way, Go's deployment model doesn't have much to do with the language and it will become more complex if the language becomes more popular.

mike_hearn 12y ago

What kind of insanity? Are you talking about desktop or server apps? Whichever you mean, you can create apps that have self contained JREs with the javapackager tool. But most server setups don't seem to need it. If you have a broken IT environment where your admins refuse to upgrade the JVM, that can be an issue, but then you might find yourself being told to stick with an obsolete version of Go in future too in such an environment.

vessenes 12y ago
Hi Mike! Fancy seeing you here. I'm not trying to start a religious conversation; so with that caveat, I'll respond -- By insanity, I'm referring to the need to grok stuff like this page: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html http://maven.apache.org/guides/introduction/introduction-to-... Building a large java application is not something I'm an expert at, but I have spent many hours of my life fighting with maven and ant and dependencies, happily some time ago. By comparison, there's "go build". Or if you need auto-cross-compiling, there's goxc. While an IT manager might limit the version of go on a server, it would have no impact on most go developers; I can build a self-contained binary for linux right from my Macbook Air in under 2 seconds with a single command. Or using goxc, I can build for all binary targets in very short order. To me reducing this sort of cognitive load on build/deployment is a HUGE benefit go provides, especially to junior developers or teams with different backgrounds.
- zak_mc_kracken 12y ago
  You are confusing building and deploying. Building in Java is also a one line command. Deploying is also often a one line command (or a one click affair). The fact that Go is natively compiled makes this kind of deployment a bit more problematic, and it's bound to get more complicated once Go supports dynamic loading. I'm not trying to make a judgment call between Java and Go here, just pointing out that saying that one of these language is insanely more complicated to deploy than the other doesn't make much sense.