Hacker News Reader

> C# has had async, await and parallelism for years

For Scala developers, there's Scala Async, which is exactly what C# "async" is, implemented as a library: https://github.com/scala/async - plus Scala's `Future[T]` has a better design than C#'s Task.

> node.js and libuv are taking over

And both suck in comparison with Java's NIO and the libraries that have been built on top of it.

> Low level threads in Java are so goddamned awful and unavoidable that it makes me want to pull my hair out

Low level concurrency primitives are necessary for building higher-level abstractions on top. For example I need low level concurrency primitives for implementing a Reactive Extensions (Rx) implementation that does back-pressure: https://github.com/alexandru/monifu/

> the people downvoting this have no idea what I'm talking about and don't know what coroutines are

You're assuming too much.

plus Scala's `Future[T]` has a better design than C#'s Task

Why? The one issue I have with Task is the aggravating SynchronizationContext/continueOnCapturedContext. ConfigureAwait(false) really should have been the default. Otherwise, my experience with both seems about equivalent.

You're getting downvoted because your post is "middlebrow dismissal" (https://news.ycombinator.com/item?id=5072224) which is also unnecessarily aggressive. It's quite possible for someone to know exactly what you are talking about, and still downvote it.

Regarding the technical points, having low-level mechanisms for fine-grained synchronization between threads (such as these) does not prevent you from also providing high-level mechanisms for parallelism and concurrency. In fact, it enables others to develop such abstractions in that language in question, without relying on the language itself to provide them.

> unnecessarily aggressive

Aggression that's really the result of thread frustration in Java. I hadn't read about middlebrow dismissal before, I can see how my post came off wrong. I'm glad I posted what I said however, because I the responses taught me new things.

I think you can be aggressive (heck look at Linus) but it has to be substantiate by in detail knowledge and arguments. If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. I guess take that as life advice in general.

> If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted.

My point was that a programmer shouldn't need to share memory to write concurrent code. That statement is not wrong.

> That statement is not wrong.

Yes it is. Unless you use Erlang or OS processes you are sharing memory. Or rather you not sharing it any more or less than all the other technologies you listed.

But I agree with your sentiment in general that shared memory and concurrency are not working well. That is why it is worthwhile learning Erlang if you want to be reliable, fault tolerant concurrent systems.

Also nothings stops your from using queues and threads so data is local to each thread and gets copied over the queue.

> Unless you use Erlang or OS processes you are sharing memory.

Actually, even actor-based systems share memory. If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state. Which can be different depending on whether C received A's message first or not.

> If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state.

Ok in that respect there is just one big pile of shared memory in the whole world, isn't it (maybe except for military air-gaped system). It is the equivalent of saying if A makes an HTTP post to server C the it shares memory. Well ok, I am not sure what you mean by "shared memory", usually it means living in the same heap. So can access it via a pointer or reference.

I think what people are taking exception to, is the difference between abstraction users (programmers who are writing concurrent code) who should be able to use high level concurrency idioms to hide their shared state and abstraction creators (programmers who are writing high level concurrency idioms) who need concurrency primitives to make their abstractions efficient.

If we didn't have concurrency primitives, the only high level concurrency idioms we would have would be the ones that made it into the JVM, which is a very slow process.

Atomics vs Adders aren't part of the thread mechanism. They are lower level abstractions around CAS operations, that you mostly only need care about during concurrent coding. I haven't looked at the C# async implementation, but I'd bet it uses CAS operations. Further C# most certainly has similar abstractions around CAS. Akka also is written using CAS abstractions.

Just because there are libraries that provide higher level abstractions around concurrent programming doesn't mean that lower level primitives aren't necessary. In fact, on the JVM due to it's abstraction away from the underlying machine, these sorts of primitives are more needed.

If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads. One must use atomics in Java actually quite a bit, like if you wanted a sane counter. Sharing memory across threads in Java is currently unavoidable, even when there are great libraries around. For example any kind of UI or audio or file reading and writing, or timers require having to deal with low level threads.

kasey_junk's point was that you need CAS primitives (and other low-level threading operations) in order to implement higher-level concurrency abstractions like Akka on the JVM.

> If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads.

By definition, you aren't doing concurrent programming if you aren't doing shared writes.

> By definition, you aren't doing concurrent programming if you aren't doing shared writes.

I don't understand what you mean but I like Robert Pike's take on concurrency:

"concurrency is the composition of independently executing processes"[1]

As a specific example if you don't want code to block while you're waiting for HTTP requests to finish you're going to be writing concurrent code. I don't understand how that involves "shared writes" but maybe you can explain further? I can write concurrent code that shares no memory, and I can print log statements that show me it's executing concurrently, so I think you may be mistaken.

[1] http://blog.golang.org/concurrency-is-not-parallelism

> "concurrency is the composition of independently executing processes"[1]

Yes, and that implies shared writes.

> As a specific example if you don't want code to block while you're waiting for HTTP requests to finish you're going to be writing concurrent code. I don't understand how that involves "shared writes" but maybe you can explain further?

That's not really concurrent code, because there's a clear happens-before relationship between making the request and executing the callback "onComplete", so the original request and the ensuing onComplete continuation is serial.

However, this particular example uses concurrency under the hood to work. You don't know when the request will be ready and you need to execute this onComplete and the next specified onComplete (if multiple callbacks are specified), so under the hood you need a shared atomic reference and synchronization by means of one or multiple CAS instructions, which also imply memory barriers and so on.

I agree with bad_user's points, but I would like to add my own phrasing in support of his points.

Concurrency with "independently executing processes" are not strictly independent. There must be some communication between the processes, otherwise they cannot coordinate to achieve the same task. A typical mechanism is to have a shared queue between the processes as the only point of communication - use of that queue will involve "shared writes".

People build abstractions on top of such mechanisms which hide these shared writes, but they are still there. And that is part of bad_user's point: even though you, yourself, are not actually writing the code for a "shared write", you must call code that eventually performs one.

Every concurrent system in the world has shared state. If nothing else being able to signal that you are done (or yielding) is shared. Many common concurrency patterns get around a lot of the logic problems in concurrency by not sharing mutable state, typically in the form of message passing patterns. But how do you suppose those messages are passed? Via shared state of course.

That is when having good primitives around compare and swap becomes important. Adding these primitives makes implementing those higher level abstractions on the JVM possible for people who are not implementing the JVM, that is as libraries.

I haven't looked at the C# async implementation, but I'd bet it uses CAS operations.

Yup, the C# library is called Interlocked and it provides a variety of atomic operations. C# also has ref, which allows variables to be passed by reference, which greatly increases the power of the library.

I find Interlocked absolutely essential for getting maximum performance -- like in implementing lock-free data structures.

You have librarires such as https://github.com/kilim/kilim or http://docs.paralleluniverse.co/quasar/ for Java lightweight threads

Yeah there are some nice libraries, my preference is Akka, but I think Java needs real native coroutines:

https://en.wikipedia.org/wiki/Coroutine

https://en.wikipedia.org/wiki/Coroutine#Implementations_for_...

Akka doesn't have native coroutines / lightweight threads, it relies on regular JVM threads. it does reuse them for Actors but it dons't do the same things as Qasar (user level threads via bytecode instrumentation). I'm a big Scala and Akka fan, but thought it's worth noting.

Akka is a library not an extension of the JVM so it would not be able to provide native features to Java. I didn't know that Quasar did more. One is able to write much better concurrent code with Akka than with vanilla Java but I think you can still run into threading issues where Java makes this unavoidable, like when playing with audio.

Quasar also relies on JVM threads. Akka's lightweight actors are just as native as Quasar's lightweight threads.

(main Quasar author): Akka actors are nothing like Quasar fibers (or even Quasar actors). Quasar provides true lightweight threads - though they're not "native" to the JVM, they're as real as Erlang's processes or Go's goroutines - while Akka actors are a formal way to organize asynchronous callbacks.

Adders were easily implementable and readily available pre-Java8, basically they need the new JMM from java5 on (i.e 10+ years). Hence, no really a hot topic, yet very nice to have. However any serious project already had something of the sort.

On the other topic: async/coroutines/friends etc have nothing to do with "adders". The latter are a low-level concurrency primitives that enable fast counters and the like. Feel challenged to write a good a simple counter (like page hit) with co-routines or sync.

First, Java has fibers[1]. Second, Adder has nothing to do with that. It's a low-level concurrency construct, that many languages would be happy to have. It doesn't matter if you use kernel threads or fibers, concurrent data structures are a great tool, and Java leads the way in that area.

[1]: http://blog.paralleluniverse.co/2014/05/01/modern-java/

>node.js and libuv are taking over, and Akka has gained enormous popularity and yet real coroutines in Java aren't even on the horizon

There is something like that for Java

http://docs.paralleluniverse.co/quasar/

Android has async-like abstractions in its API. But I like threads better anyway.

> Wow man Java's still all in with it's terrible threading mechanism all the while C# has had async

What is so bad about threads? Why do you need co-routines?

> What is so bad about threads? Why do you need co-routines?

You aren't forced into sharing memory across parts of your program that have no business sharing memory. In Java you can easily end up in a situation where you can look at a program and not know what thread one line is executing in versus another line in the same file. The same instance of a class may be referencing one of its property in one thread or another, and that's sharing memory across threads. A simple if statement may fail you when you share memory across threads because after the if statement checking shared memory evaluates the underlying value for that property it may have changed before the next lines after your if statement executes.

Coroutines as they exist in Go or C# help programmers write code that don't share memory across threads. Akka does this, try it, it's amazing. Java needs native support. Threads are shit. Sharing memory across threads is a nightmare.

Edit: If you're going to downvote, explain why I'm wrong.

Coroutines also share process space, they're just deterministic so you don't need locks as frequently. The real benefit is lower overhead in terms of memory use, creation and task switching.

> You aren't forced into sharing memory across parts of your program that have no business sharing memory.

I think you are confused (but I didn't downvote you, someone did and then also downvoted my post, was it you ;-) )

Anyway. Unless you use Erlang or fork OS processes you will be sharing memory between your concurrency units.

So learn Erlang it will do you good

http://learnyousomeerlang.com/content

You can build java threads with queues and that works fine. You can shoot yourself in the foot with Go or node.js (probably more so).

You can also have separate heaps per thread in Java if you use a JVM that supports it, such as Avian: http://oss.readytalk.com/avian/