Hi Mike,
I see you point. To address several kinds of concurrency problems actors are a big hammer. Channels in Go combined with so-called goroutines are a nice and easy way to do concurrency. You can use channels for low-level stuff. If you need a bigger hammer, you can build actors on top of channels. In case you didn’t play with Go, here is a good primer to see what it is about: http://golang.org/doc/effective_go.html#concurrencyI believe this does not compete with Kotlin ;-). Go and the JVM are really very different things … It’s just about talking about something that has a hammer of the right size.
In Go threads do blocking takes on channels. In case the channel is empty the runtime withdraws the thread from the channels and assigns it to a non-empty one. This can not easily be done in Java. So instead of doing blocking takes you have to go with asynchronous callbacks. I’m playing with a little framework to get this accomplished for Java8: https://github.com/oplohmann/Wilco It is still sketchy and yet not free of timing problems. If you are interested you can have a look at classes PingPongTest and PipelineTest to see how it works. These two test classes try to do the same thing as in some well-known Go samples (http://talks.golang.org/2013/advconc.slide#6 and https://blog.golang.org/pipelines). Unhappily, class Channel contains some synchronized blocks. I have no clue how I could replace them with CAS-style operations. And this is worrying me, as this will have bad lock contention. Maybe the whole thing will die because of this. But it is fun to play with it.
I don’t know whether you have seen JDK8 CompletableFutures. The also provider a smaller hammer than actors and may be a possible choice for certain kinds of situation in your framework.
Regards, Oliver