News for hackers. Stuff that matters.
Re:Sane Concurrency with Go by bad_user on Thursday March 13, 2014 @03:51AM (#7390524)
Speaking of the JVM, Scala has immutable data-structures. You stick one of those suckers into an AtomicReference and presto you've got a thread-safe data-structure. And for more complicated scenarios, you also have Scala-STM: http://nbronson.github.io/scala-stm/

Even though the concurrent data-structures in Java's library are efficient and well built, they remain error-prone because thread-safe operations are not composable. Working with immutable data-structures in a high concurrency scenario is the best thing since sliced bread.

I do agree with your point - sane concurrency implies using the right abstractions for the job and there are cases in which you need shared memory storage. The JVM is in fact great because it does 1:1 multithreading, because the GC is so good that it allows you to be a little wasteful and because it provides the required concurrency primitives to build whatever abstraction on top that you desire.

For Scala + the JVM, just to enumerate - you've got actors by means of Akka and it's pretty capable as it's flexible and it allows you to manipulate/coordinate entire clusters of remote actors (and of course there's Quasar that does the lightweight threads thing and I'd love a comparison between the two btw), you've got the Future/Promise concept baked in and with a sane design [2], with C#'s "async" by means of a library that will be part of the standard [3], you've got great immutable data-structures that also have parallel extensions [4], you've got RxJava/RxScala for processing streams of events reactively [5], or Iteratee IO for safe processing of data streams [6], or shared transactional memory that I mentioned above [7] and of course things inherited from Java, like NIO which in spite of its flaws it's the sanest cross-platform abstraction over native APIs for async I/O, plus as I've said, the best cross-platform concurrency primitives you can get (e.g. I still get boners every time I use ReentrantReadWriteLock).

[1] http://akka.io/

[2] http://docs.scala-lang.org/overviews/core/futures.html

[3] https://github.com/scala/async

[4] http://docs.scala-lang.org/overviews/parallel-collections/ov...

[5] https://github.com/Netflix/RxJava

[6] http://www.playframework.com/documentation/2.2.x/Iteratees

[7] http://nbronson.github.io/scala-stm/

Re:Sane Concurrency with Go by pron on Friday March 14, 2014 @06:41PM (#7402481)
> ... immutable data-structures. You stick one of those suckers into an AtomicReference and presto you've got a thread-safe data-structure.

Thread-safe – yes (and Clojure does this beautifully; in fact any Clojure DS is thread-safe); concurrent – not really, because you can only have one writer at a time, which simply doesn't scale for large data structures.

> I'd love a comparison between the two btw

Quasar has true lightweight threads (M:N multithreading as in Go or Erlang), and an (optional) actor system built on top. Quasar actors can and should block as much as you want, have selective receive (just like Erlang), and are especially easy to use. Also, Quasar has Java and Clojure APIs that feel natural and idiomatic in both languages.