3 ms·
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 t
by 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 agoYou 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.