15 ms·
It goes deeper than that. The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in
by jlouis 14y ago
It goes deeper than that. The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter.
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.
- eternalban 14y ago> The prime difference is in the stance: "Is concurrency a library or is it a built-in feature?". In Java, it is the former, whereas in Go, it is the latter. 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.)
- jlouis 14y agoI would not be surprised if it turned out to perform extremely well - and perhaps even outperform Go. On the other hand, performance is not everything when it comes to writing large software systems. Again, my Erlang experience is that even if we are "hellishly slow" because every message is a copy in Erlang, it doesn't matter. For large software systems it turns out that the architectural design is what is the driving factor to program speed. How fast you pass a message is only part of the whole thing. 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.
- eternalban 14y agoIf it didn't, the fault would be mine. A dip to unsafe and it is effectively as bare metal as 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/discussion https://groups.google.com/d/topic/golang-nuts/8k59RgkeJ6s/di... (grep for Andrei Alexandrescu of D fame and read on ..)
- msbarnett 14y agoGDB has full support for Go now. So how easy debugging in Go is depends on your opinion of GDB, to some extent (the learning curve is steep but it's a powerful tool, IMO).
- Evbn 14y agoThe GogC++ engineers programming the custom computing hardware running communicating over custom network hardware with custom network software disagree with your assessment that "architectural design" is all that matters to obtain performance. When your compute budget is around a billion dollars per year, constant factor speedups are highly relevant.
- azth 14y agoI would like to do that for kicks. What numbers would be interesting to look at in terms of benchmarking (throughput, response times, waiting times, etc.)?
- Evbn 14y agoIsn't there a famous paper entitled "Concurrency is not a Library" due to memory-model issues and somesuch? Ah:"Are Safe Concurrency Libraries Possible?" And if the title is a question, the answer is no. https://docs.google.com/viewer?a=v&q=cache:fR6o9U8aDHEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.53.8275%26rep%3Drep1%26type%3Dpdf+&hl=en&gl=us&pid=bl&srcid=ADGEESgljq-nc3rrcSGWU5QROAUD3IK_wXVa0qGwH2urLtihKB5RtOQ-yLMG9k8Wytp95MS8Ql3qqYZiSgUHVffwS1G7PdsY6jNCdvyK4JH85nTGkMVgatSPYvni657EwZGAGeIanrn1&sig=AHIEtbSBHbgfD2sL6DE1X-fSxqZbSxq1Bg&rlz=1Y1PGWF_en___US489 https://docs.google.com/viewer?a=v&q=cache:fR6o9U8aDHEJ:...