10 comments

[ 4.2 ms ] story [ 37.7 ms ] thread
I'm really excited about this library -- thanks Leon and Climate for releasing it!
I'm the author, and I'd be happy to answer your questions!
Sounds like a cool library but I'd be embarrassed to say I use something named after the dude from Primus
Les actually spells it "Claypool", without the e. It's not named after him, I assure you.
Anyone that knows that has no right to complain about it.
Why be embarrassed? He is a virtuoso freak. Primus could have been one of the all time great bands if wasn't for Claypool's singing and lyrics, but his bass playing and the instrumental sections of their songs are awesome.
Up until now, managing a thread pool in Clojure still meant dropping back to Java and doing something like this:

http://www.javacodegeeks.com/2013/01/java-thread-pool-exampl...

Clojure makes Java interop easy, but I hate every moment that I have to use Java, rather than a library that offers me idiomatic Clojure.

If I understand Claypoole correctly, it removes the need to drop down to Java. No more ExecutorService.

To my mind, this is awesome.

I asked for something like this a few weeks ago in #clojure, nobody had a solution. Thanks!
While this looks useful, the example is precisely the sort of problem for which threads aren't useful.

Parallel IO doesn't (necessarily) need to use threads and an explicitly async API is more flexible and usually easier to understand, especially with CSP like core.async.

It's true that parallel IO has less overhead with an asynchronous API, but I disagree about it being easier to understand. You have to set up callbacks or start your processes and then wait, and you have to work harder to manage the degree of parallelism.

If parallel IO was all we needed to do, asynchronous APIs would be the sensible choice, but for managing parallelism while chaining IO & CPU work, sharing pools across multiple simultaneous requests, Claypoole's a pretty nice tool.