My claim is that Go's advantages are far, far too small to outweigh not running on the JVM. (also, I think Clojure > Go -- no need for Java in the equation -- but that's not my main point)

You see the JVM as an asset. Many consider it a liability.

And programmers in the New Jersey school (see Worse is Better) are unlikely to ever stomach Clojure.

These differences are more in the realm of deep allegiances and HN comments will probably be limited to revealing allegiances--they have little chance to sway the reader one way or the other.

Might as well say, "MIT type with love for the JVM? Choose Clojure. New Jersey type with love for native code? Choose Go".

I realize I've started a pretty ridiculous language war; that was not my intent. But I still cannot understand why anyone would want to use a language that is mostly meant for non-constrained environments, does not provide some major productivity advantages over JVM languages while being slower than JVM languages. I would totally consider using use Go if it targeted the JVM.

You say some people consider the JVM a liability. Can you please explain why? As far as I can see, the JVM has two disadvantages: a high RAM footprint and a slow startup time. But on server-class hardware (and I believe that's probably the main environment for Go), it's hard to beat the JVM's performance, and nothing even comes close in providing similar monitoring. So -- and I'm asking this completely seriously -- why would anyone consider the JVM a liability in such an environment?

I don't understand either. Let history decide, we use Clojure & Java for server-side stuff it saves us countless hours/problems.

I have another problem with the JVM and it's oracle.

>I haven't measured, but I'd guess that the language spec of Go is shorter than the specs of each of those other languages.

Doesn't matter, since you'll find huge large holes in libraries, tooling, ecosystem and maturity in Go which can be easily filled in Java+Scala/Clojure, and which nullify any "smaller spec" advantage.

For example there is not one mature and complete web framework in Go. Several for all of Java/Scala/Clojure. There is no good RBDMS support in Go. As good as it gets for the JVM languages. Etc...

Naturally, Go users do not believe that complete web frameworks or RDBMS support is a desirable feature.

That is a bit disingenuous. There is an SQL interface driver in the stdlib here[1]. There are several[2] implementations available which build apon it.

There are several[3] (scroll down to the relevant section) web frameworks too.

I personally tend to prefer using the gorilla toolkit[4], in combination with the stdlib http and templating stuff. It should be noted that my current usages for Go include an API service, command line tools, and a proxy. Certainly not much html generation going on there by any means.

[1]: http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/