> I'm not so sure about that. If I'm not mistaken, most Go objects are mutable and can still be passed as messages.

This is actually a complex subject. Go has mutable objects yes. But it also doesn't treat everything like an reference type. You have to send a pointer as the message if you want the receiver to be able to modify the object you sent. (slices and maps are the exception to this) I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.

This to me makes Clojure less relaxing. In fact Clojure is not relaxing it's challenging which can be enjoyable but I wouldn't say it's what I want to do everyday for my job. Go I could easily see myself doing it everyday.

As I said Go has a lot of good qualities all in one package. Clojure has some of those qualities but not all of them.

The pointer to the compiler api is interesting. I hadn't seen it before. I don't see any way to serialize a source tree in there but that might be just for lack of searching. I wonder why things like gofmt and company don't exist in the java toolchain already. I mean outside of third party IDE's.

>> * I actually don't think immutability is as key to concurrency as it gets hyped to be. Clojure which I've used and enjoyed does tend to get in your way with the immutability by default.*

I don't want to join into a language war, but I wanted to point out two things with this statement:

1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.

2- Rich Hickey worked on massive telephone systems and created Clojure, at least in (large) part, out of frustration of dealing with mutation.

So there's a long line of research backed by "real world" experience showing mutation not holding up well for concurrency. Erlang is another example.

Regardless, I do agree that immutability may not be what it is hyped up to be, especially if you are looking for the mythical silver bullet, but it most certainly isn't over-hyped if you compare it to mutation, and the ideas are still quite young and being tested. Give it 20 years and I suspect there will be another paradigm shift at some point.

My point is that Go gives you the option of immutability. Not immutability or something in between. I frequently send messages using non reference types which incurs a copy but means that I don't have to worry about who owns this code. It's easy since Go has pointer and non pointer types. Java has reference types and you have to design the object to be immutable by hiding fields behind methods and using annotations. Clojure goes to the other extreme. Go sits in the middle. Which is relaxing.

Go can't do immutable updates efficiently (yet) because it doesn't have a persistent data structure implementation for vectors, maps, sets, etc.

Java has a keyword 'final' for immutable objects.

> 1- I can show you video lectures from 1985 that discuss mutability -vs- immutability in concurrent systems. Immutability won this war, at least in the research realm, 30 years ago.

Maybe, but concurrency based on mutability seems to have won this war in the real world these past thirty years.

Immutable systems might be easier to design in theory but we haven't seen this proven in the battle field yet, and the fact that most of the concurrent code today runs on mutable structures shows that it can be done.

Immutability has worked out really well for a lot of real-world systems built with Erlang.

The main (and close to only) user of Erlang was Ericsson, and here is what the Wikipedia has to say about it [1]:

"Shortly thereafter, Erlang was banned within Ericsson Radio Systems for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson"

Not exactly a strong endorsement for Erlang.

[1] http://en.wikipedia.org/wiki/Erlang_(programming_language)

"The ban caused Armstrong and others to leave Ericsson.[6] The implementation was open sourced at the end of the year (1998).[3] The ban at Ericsson was eventually lifted, and Armstrong was re-hired by Ericsson in 2004.[6]"

It is really hard to imagine that you made that excerpt in good faith. Read the very next sentence in the article.

Alright, I'm sure some people find Go's particular combination of features appealing. For me, a language has got to be so unbelievably awesome to consider leaving the JVM, and seeing that some of the most awesome languages target the JVM, that language better do something that would truly impress a veteran like me. There's only one non-JVM language that I'll use for some very specific applications, that I think is all that: Erlang.

I'm not sure if it's just a mindset thing or the stuff I've used it for, but I've never felt the immutability got in the way, it's one of the things I miss most when using other language.

> most Go objects are mutable and can still be passed as messages.

Go makes it easy to get right. It doesn't make you get it right.

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

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/

It depends what you want to build I guess. Go has a much smaller surface or things to learn if you know POSIX already. It's fast startup times makes it also a good contender for command-line tools.

+1 for alternative languages like Clojure and Scala.

I recently (more or less) shut down my consulting business to do other things and since I no longer need (so much) to fit in with customer's tool chains, I decided on Clojure as a great general purpose language that is also a lot of fun to develop with. I could make the same comment about Scala or JRuby if I had chosen either of those fine languages.

Really, the JVM ecosystem rocks.