In my experience, having concurrency primitives in the language tend to integrate better than having them in a library - for the simple fact it saves some space when writing and reading programs.
As for the choice of `java.util.concurrent` over goroutines it again depends on your stance. j.u.c provides you with some excellent high-level primitives on which to build concurrency. But these primitives are easy to build in Go with its concurrency primitives. Some, like `BlockingQueue<E>` or `Future<V>` are directly isomorphic to a channel or a simple goroutine/channel invocation respectively. It is a matter of opinion whether or not one should actually do these kinds of implementations themselves.
A more important difference, however, is that Java operates on Threads as the "smallest" primitive, whereas a goroutine is a light-weight "thread". That is, you can easily have tens of thousands of goroutines running, but you do probably not want the same amount of threads in a Java system. For that, you need stuff like kilim.
In my experience, I am a professional Erlang programmer, the ability to run extremely concurrent threads/processes is a game changer for much of the code you will be writing.
Fully agree. But in case of Go, the language feature is non performant.
cd $GOROOT/src grep -r Lock *
You are strongly motivating me to write Go channel semantics over Java's (nio) Selectors and j.u.c to demonstrate a point... (Don't. I've other things to do.)
The real question to ask is how good a language is for the large scale software design. Certainly Java has proven itself to be there. Go is still young, but it specifically targets some of the problems in the same area as well. In my experience, debugging and the ease of doing so is also very important. And I don't know much about how easily this is to do in Go.
> The real question to ask is how good a language is for the large scale software design...
Agreed. A comparison with Java at this point would be unfair given the massive investment made by the industry in tweaking of the platform over nearly 2 decades. I think Go is a very promising language.
One simply hopes that the leading lights of the language/industry do not stoop to making threadbare (npi;) claims of superiority over other, equally viable, languages. After all, "it's just code". (PL religious wars are entirely boring.)
> debugging
Go has very good profiling and data race [1] detection tools. As far as debugging goes, I'm in the printf school of debugging (even on Java) and so far so good, so I can not speak to that.
[1]: it is not a pure CSP system. See this very interesting thread: https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/di... (grep for Andrei Alexandrescu of D fame and read on ..)
Ah:"Are Safe Concurrency Libraries Possible?" And if the title is a question, the answer is no.
(The nearly cult-like mentality of some of Go programmers is really quite annoying.)