> You deploy. You're done.

Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then...

Yeah.

The ability to tune GC and availability of monitoring solutions are things I consider as big pluses for deploying on the JVM.

I would love to have a GC which tunes itself to accommodate the workload. On the JVM, G1 is a step in the right direction. How does Go's GC work in this regard - does it auto-tune itself?

Also, how are Go programs monitored in production? Are there tools like AppDynamics, NewRelic, JConsole or similar APM/telemetry solutions available to monitor Go applications?

Setting memory parameters and tweaking them would be similar to deciding what compilation flags to use when compiling your program. I also much prefer profiling over JMX than re-compiling the application with the profile flag activated and re-deploying.

Yeah. But you don't have to, you're literally complaint that the user has options. It's not like Go doesn't have a GC either.

And the biggest joke is that when you tweak the default settings you often end up making it worse.

The JVM has generally excellent performance with the defaults.

Exactly, and Go's GC is years behind the JVM.

As someone else who has been deploying Java applications for years, I'm not saying it's hard, but you have to take care when upgrading the JRE on a server, because with most setups (such as the default Sun JDK RHEL packages) it's a shared resource. You can go ahead and bundle a JRE with your jars. With Go this specific problem doesn't exist.

Fair point. I've always used the approach of dedicating a machine to one particular application (using virtual machines once those became available), so the impact of upgrading the a global JRE is limited.

I did once work on a system where we installed two JREs in parallel, and selected which one to use for the app based on an entry in the manifest file. That let us upgrade Java versions under application control, without requiring sysadmin intervention. Took a couple of lines of shell script.

I think you must agree that no matter how painless it is, binary < JAR + JRE, in terms of deployment effort.

Depends. For me, creating an uberjar with my default project/package manager is easier than to setup cross-compilation with Go. YMMW.

Why don't they just combine the JRE and JAR file? Then I can be sure it works when I download it.

For the same reason you don't deploy Windows, BSD and Mac OS X binaries of your Go program to a Linux server.

Yeah I use the Linux binary, I'm not sure what you're saying here.

The JRE is platform specific, the JAR isn't. Bundling them makes little sense.

I think it makes a lot of sense. I can download the Windows version of an app and double click on it and it runs. As opposed to I double click on it and it's all "oh you don't have a JRE" or "you have the wrong JRE, mysterious error" or "you need to install this JRE", or it installs a JRE for me, but another app requires a different JRE.

I'm surprised you didn't mention Java compiles to byte code which is then JITed for the processor on which you're currently executing - I don't need to recompile for every platform and I still get native performance. This has been Java's primary strength since the introduction of JIT. Even better, I don't have to use Java to create the byte code. My favorite happens to be Clojure but you have several language options to suit your needs.

You never had any classloader issues with things like logging libraries and their configs or XML parsers? No versioning problems with dependencies of dependencies getting confused at runtime? No inconsistent clasloader behaviour with differnt Java EE containers?

I'm not saying that library versioning and dependencies are not a problem with Go. Quite the contrary. But it's a compile time issue. There are far fewer surprises at runtime and that makes deployment a lot easier.

    > You install a JRE on the machine. 

Whoops. That's where you lost me.

Fair enough. I certainly agree that Go is an excellent language for people incapable of doing basic stuff like this.

I'm perfectly capable, I just don't see the reason. Why should I install a JRE to run your program? The JRE has nothing to do with your program; it's incidental complexity. Go gives us a way to eliminate that incidental complexity and so is a step forward.

hmm, well we can dumb things down if you really need it. I think things are already pretty simple though.

I suspect this comes from classic Java setup of using an application container like weblogic, websphere, JBOSS or web containers like Tomcat.

> You install a JRE on the machine. You deploy.

That's two steps. The first one can ruin your day.

How so ? It takes minutes to install it.

Just download it, copy it and set JAVA_HOME to make it easier for other applications.

I've done this on hundreds of servers during my lifetime and never once had an issue.

Oh, look, there's already an antique jre installed on my os, not compatible with the particular jre needed by this application, which I first need to uninstall. And then hope that it doesn't break anything else in the process, because I haven't been following the minutae of java development environments for the last n+1 years...

I think it falls solidly in the "easy if you know it, and a wasted q hours if you don't" category.

That's why he said to set a JAVA_HOME so this JRE can exist separately from the system one.