Surprised that a thread about CSP in Lisp doesn't mention Clojure's core.async. CSP in Clojure is implemented as just another library and it's rock solid. While I don't claim to understand the implementation in detail, it's one of the more interesting and high leverage uses of macros I've seen in Clojure. It makes concurrent programming a breeze in Clojurescript as well, despite JS being single-threaded.<p>As someone who programs in both Clojure and Go there's absolutely nothing I miss from CSP in Go, and I would much rather do concurrent programming in Clojure.<p>Rationale: <a href="http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html" rel="nofollow">http://clojure.com/blog/2013/06/28/clojure-core-async-channe...</a><p>Code: <a href="https://github.com/clojure/core.async/blob/master/examples/walkthrough.clj" rel="nofollow">https://github.com/clojure/core.async/blob/master/examples/w...</a><p>Presentations: <a href="https://github.com/clojure/core.async#presentations" rel="nofollow">https://github.com/clojure/core.async#presentations</a>
Sorry for the nitpicking, but:<p>"One of the things that Go (and Erlang) got right was using channels as the main mechanism for synchronising and communicating between threads."<p>Erlang doesn't have threads and doesn't use channels either.<p>Erlang has lightweight processes, which might map onto OS threads (but user code has no control over this).<p>Erlang uses async communication which is always non-blocking (of course, you can emulate sync communication, the gen_server:call behaviour in the OTP library does that, for example).<p>Otherwise, spot on! :)
This illustrates the power & the problem of Common Lisp: the power is that it really is easy to add channels (and pretty much every other feature) to the language yourself; the problem is that it's generally easier to write your own code to do this than to use (or fix …) someone else's.<p>I've experienced exactly this: I too looked at ChanL. In my case it had a bug for one of my use cases, and it was honestly easier to roll my own channels (with, of course, their own bugs) than to understand & fix ChanL's bug.<p>The problem is that this leads to a proliferation of different libraries, all doing similar things. The power is that one really can write just about anything, and it will work well enough for your use case.
The book by Hoare on CSP <a href="http://www.usingcsp.com/cspbook.pdf" rel="nofollow">http://www.usingcsp.com/cspbook.pdf</a> published in 1985 actually used Lisp:<p>> The proposed implementations are unusual in that they use a very simple purely functional subset of the well-known programming language LISP. This will afford additional excitement to those who have access to a LISP implementation on which to exercise and demonstrate their designs.
I think a lot of people in this thread are being absolutely ridiculous. It's not easy to implement channels in Lisp because of Lisp, it's because the work is already done for you.<p>What mainstream language doesn't have structs, condition variables, locks, threads and... Wait, I think that was all of it? Oh, and linked lists. I mean come on, you could do this just as easily in Java.<p>And all this talk of the Lisp curse, Jesus Christ. I mean, there's a point in that there are a lot of lackluster libs (but what language doesn't have that), but Quicklisp and a switch in Lisp culture means that there's a large amount of collaboration (and usage of libs) between programmers. There's the potential to start to use the same libraries and a will in the community to do so.
Really interesting read for me as an experienced Go developer currently learning Lisp. Not sure if I will ever use Lisp or this for a real project, I see it more as some kind of Sudoku in code, and a indirect training ground for Elixir (which is a wonderful complement to Go for backend tasks).
I once tried ChanL but it was buggy, and concurrency bugs are the worst to debug.<p>lparallel on the other hand was solid to me, though I didn't like its API and had to (trivially) build my own message-passing abstractions on top of it.