4 ms·

You claim (as I understand): (Java + Clojure) > Go && (Java + Scala) > Go That stance seems to require a low weight on the cost of conceptual and tool-cha

by ericbb 14y ago

You claim (as I understand): (Java + Clojure) > Go && (Java + Scala) > Go That stance seems to require a low weight on the cost of conceptual and tool-chain overhead. 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. Edit: Fix spelling of "Clojure".

pron 14y ago
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)
- ericbb 14y ago
  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".
  - pron 14y ago
    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?
    - jasonjackson 14y ago
      I don't understand either. Let history decide, we use Clojure & Java for server-side stuff it saves us countless hours/problems.
    - deleted 14y ago
      [deleted]
  - jacquesm 14y ago
    I have another problem with the JVM and it's oracle.
pretoriusB 14y ago
>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...
- Evbn 14y ago
  Naturally, Go users do not believe that complete web frameworks or RDBMS support is a desirable feature.
  - stock_toaster 14y ago
    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/ http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/

by ericbb 14y ago

pron 14y ago

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)

ericbb 14y ago
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".
- pron 14y ago
  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?
  - jasonjackson 14y ago
    I don't understand either. Let history decide, we use Clojure & Java for server-side stuff it saves us countless hours/problems.
  - deleted 14y ago
    [deleted]
- jacquesm 14y ago
  I have another problem with the JVM and it's oracle.

pretoriusB 14y ago

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

Evbn 14y ago
Naturally, Go users do not believe that complete web frameworks or RDBMS support is a desirable feature.
- stock_toaster 14y ago
  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/ http://golang.org/pkg/database/sql/ [2]: http://code.google.com/p/go-wiki/wiki/SQLDrivers http://code.google.com/p/go-wiki/wiki/SQLDrivers [3]: http://go-lang.cat-v.org/pure-go-libs http://go-lang.cat-v.org/pure-go-libs [4]: http://www.gorillatoolkit.org/ http://www.gorillatoolkit.org/