>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...
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.
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...