Hacker News Reader

Comment by pron | Hacker News Reader

... and those don't even include Java's long list of concurrent collections.

Or the other Collection implementations offered by https://code.google.com/p/guava-libraries/.

Or the ability to write collections in the first place, as enabled by generics. You can't even write a collection in Go unless you're dealing with interface{} or unsafe.Pointer and casting a lot.

I really like the language, enough to use it and work around the lack of generics, but that's a glaring weakness. They need some way to enable container classes.

With Go, the programmer will typically not be using data structures that are concurrently accessed from multiple goroutines. It is considered more idiomatic to have one goroutine controlling a given data structure, and have the others communicate with it via channels.

That approach has vastly different performance characteristics.

That is only one way of doing things. Even though channels facilitate that method, it is not unidiomatic to not use them.

Channels are a way of queueing work, which is great for many use cases.

You can use mutexes and shared memory if your situation calls for it. For example, if I am doing a graph traversal concurrently, I can use channels to send the work to many listening threads as I traverse that graph synchronously.

If for some reason, I need to update that graph's representation asynchronously, I may need to use mutexes to lock the graph since the graph is now shared memory.

... and the concurrent libraries of futures, fork-join, tasks

Java's concurrency primitives and libraries are really overlooked in these discussions. Is the syntax too off-putting, or is it merely that Java is unfashionable?

Very much unfashionable for the HN crowd. Most of the new research in concurrency is happening in Java and funded by the high performance trading industry - an industry which is very far from the HN crowd. The new Java8 stampedlock is a good example. It's possible to implement it in C++ as well, but because of the guarantees required by the lock it is a very difficult lock to integrate into C++ code. On the other hand, the JRE guarantees the correct constraints for Java code making a stampedlock very easy to use [1]. The performance of a stampedlock also seems to be the best case for any multi-reader environment. [2]

[1] http://concurrencyfreaks.blogspot.com/2013/11/stampedlocktry...

[2] http://mechanical-sympathy.blogspot.ca/2013/08/lock-based-vs...

I find your claim that most new research in concurrency happens in Java strange. Perhaps you are unfamiliar with academic research in concurrency and parallelism? A way to get a small taste is to look at recent papers from the conference Practice and Principles of Parallel Programming (PPoPP).

If Java is involved, it's more likely they're interested in cutting developer costs than doing any "new research." That isn't to say they aren't doing any "new research," or that the research quality is poor, or anything negative at all, really. It's just a restatement of the observation that the labor market for Java developers is quite different from C developers or C++ developers (there are a lot more of the former than of the latter--a lot more).

The syntax tends to be a bit verbose, that is true. Java 8 will help a bit there.

But the major problem is that many of the Java bashers tend to criticise without knowing what is possible to do in the Java ecosystem.

I don't think there is anything wrong with Java as a language, but I have a question for you. Does Java's concurrency engine allow for many threads like Go or is it similar to C# in how your threads are not lightweight and are therefore limited to ixN where N is the number of CPU cores and i is a small integer < 10.

Java doesn't have a "concurrency engine", but a very large set of concurrency primitives: schedulers, locking and lock-free data structures, atomics etc.

To answer your question, yes: my own library, Quasar[1], provides lightweight threads for Java.

[1]: https://github.com/puniverse/quasar

The Java language specification does not define how threads are implemented.

The first set of JVMs did implement green threads, which are what goroutines are. Shortly thereafter most of them switched to red threads, aka real threads.

You can still find a few JVMs that use green threads, like Squawk.

https://java.net/projects/squawk/pages/SquawkDesign

Other than that, java.util.concurrent provides mechanisms to map multiple tasks to single OS threads.

You can't spawn 80 1:1 pthreads on an 8-core machine? Huh?

Operating systems have been able to handle an order of magnitude more pthreads than that since the day pthreads were introduced.

Reply on news.ycombinator.com