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.
What Clojure gives you by default, are thread safe mutation constructs, atoms, agents and refs that help a lot if you want to do simply concurrent things without worrying about race conditions.
Clojure also has support to get some data parallelism, you can easily do a lot with reducers and transducers. Its quite nice.
For more complex stuff, core.async gives you a powerful CSP library, its as powerful as what the Go programming language gives you (I think its nicer because Go has statements instead of expressions).
Because Clojure is on the JVM, you get access to all the Java stuff, java.util.conncurrent, and you can get a lot of powerful tools there (ThreadPools and stuff like that).
"One of the things that Go (and Erlang) got right was using channels as the main mechanism for synchronising and communicating between threads."
Erlang doesn't have threads and doesn't use channels either.
Erlang has lightweight processes, which might map onto OS threads (but user code has no control over this).
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).
Otherwise, spot on! :)
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.
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.
I've seen similar libraries that do the following, for example:
* Serialization and deserialization
Somehow none of these "100 line wonders" make it into idiomatic usage, despite their purported utility.
These channels as presented don't solve many problems well. They will be very slow and contentious, they will be expensive to make, and they will not guard against memory ownership issues because you're just passing pointers to objects around, which message passing is supposed to solve.
But, it'll become another library on Quicklisp that 3 people use and that people's applications will inadvertently depend on.
Lisp is a fantastic language for many things, including a plethora of production applications, but it being a local optimum for exploratory programming means we get lots of very incomplete, scratch-an-itch code that is pawned off as a library intended for mass consumption. In fact, the author links to his GitHub repository, where you find exactly this random assortment of disparate utilities.
If I had my way, the rhetoric of this post would be closer to a pedagogical exposition of channels, how they're used, what their benefits are, a proof-of-concept implementation, and a non-trivial example application. I would vehemently stay away from having the thesis be anything about Lisp or the ease of implementing small POCs in Lisp.
I couldn't agree more, that's the real problem with CL and the reason why I keep using scheme and Racket. (Well, that and the antiquated package/unit systems with multiple options and caveats.) Just take a look at cross-platform user interface library bindings, there are seemingly plenty of options, but in the end they are all some sort of unmaintained hacks that may or may not work on some implementation/platform combo. Threading itself is another example, by the way. Almost any addition to the outdated standard is a mess that sometimes works, sometimes doesn't work.
It's a pity, since CL implementations are of such a high quality (e.g. SBCL) and it offers everything a programmer can dream of.
Because the cost of acquiring an understanding of code that solves your problem might be much higher in Lisp than other languages, if the hypothesis is correct that the language facilitates the creation of bad half-baked libraries.
Just to give a somewhat figurative example, the jungle is a much more hospital environment for life in general than temperate environments (it's warmer, full of nutrients, bathed in constant solar energy).
However most humans didn't manage to really expand into the jungles successfully until the advent of modern medicine, because the life there was so prolific that there were all sorts of nasty parasites and diseases, and everything you build sinks into the jungle within years.
Lisp is like that jungle -- everything just grows fantastically easily, but paradoxically that makes it harder to separate the chaff from the wheat.
While there are some folks  that have the time, energy, and brilliance to build things from the ground up all themselves, I unfortunately do not. Moreover, in a collegial work environment, this means the burden is on me to test, document, communicate, and educate on this library. There's enormous additional complexity and risk that comes with building from scratch things like these which change the whole programming paradigm of your application—again, especially in a coworking environment.
 Donald Knuth and Fabrice Bellard, to name a few.
It is odd, because the "micro library" world ostensibly fixes this by greatly limiting the scope of a dependency. However, it also encourages chaining yourself to many other entities. And it is always the mistakes that people remember, such that anyone that has been burned will remember how it was enabled by micro libraries.
I have no problem with micro-libraries. In fact, I developed on the notion of the micro-est of libraries: a library generator that gets down to function-level dependencies .
Actually, you sort of do. You may not know it yet, if you were fortunate enough to never hit a problem with an update to one of them.
It is amplified when folks push them with no caveats. Some of us remember being burned in ways this allowed.
A lot of hardcore Lisp aficionados do the equivalent of a mathematician writing a "sketch of a proof" and saying "left as an exercise", without ever writing the details of the proof. It's occasionally aggravating when you pull in a library and discover that this is the case.
To be clear, there are many Lisp folks do not do this. Some go the full mile and implement something completely and robustly. Edi Weitz has been the canonical example in the community.
You might want simplicity, but users also want performance. So a complete solution will be performant, but simple.
You have one use case, but other users have others. A complete solution will work in as many use cases as possible given its constraints.
Scala's parser combinators are a good example of a complete solution. It offers the "elegant" solution of parser combinators. But it also offers an implementation of this using things like Packrat parsing that are extremely efficient.
The non-complete example of this is someone who writes a parser combinator library that is simple, but simply not performant for real world use. For example, you might write a simple version in Python, but not properly apply TCO and so your parser can't handle deeply nested structures because of a stack overflow.
With regards to owning code, I remember hearing that it took 9 years of the initial publication of quicksort for there to be a bugfree implementation of it. Even easy things can be tricky.
Well, comprehensive unit tests for a start...
That's exactly "too powerful for its own good". It's so easy to write a half-assed sketch of a library that nevertheless gives you some new powerful feature, that some people end there, and publish the sketch that was enough for their use case.
I actually think Quicklisp has helped. It's even easier to do (ql:quickload "foo-lib") than it is to write my own foo library.
This is not "left-pad" either. I'd say you have the same problems in C or C++, where people are reluctant to depend on libraries they don't control or appear to be bloated (boost, etc.). As far as Lisp is concerned, this post talks about the problem more directly: http://fare.livejournal.com/169346.html
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.
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.
> 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.
- Always follow the KISS principle (https://en.wikipedia.org/wiki/KISS_principle). Don't use Lisp's "super features" too much. The same applies to Haskell, by the way.
- Use QuickLisp as much as possible. In many cases you don't need to add your own lib. Read Quickdos [QDC].
- Comment your code well, even if others don't ever see it lest you could not be able to understand your own code later. What's the purpose of the function, which arguments are expected, of which expected type are they, what are the possible results, possible side effects, etc.
- Read and understand how Lisp's package system really works. This is important to avoid strange behaviors in your own code.
- Use SLIME (https://common-lisp.net/project/slime/). It is an awesome interactive debugger which catches bugs and presents different options how to deal with that. SLIME is also useful as manual for Hyperspec (http://www.lispworks.com/documentation/HyperSpec/Front/) which is a basic tool to look quickly for code examples.
- Don't use Hyperspec too much because it is really confusing. Use proper reference manuals like Peter Seibel's Practical Common Lisp [PCL] and Edi Weitz' Common Lisp recipes [CLR]
- If you cannot get used to Emacs (which is a wonderful tool with a steep learning curve, really the best editor ever) then you can use proprietary IDE's like LispWorks or Franz Allegro.
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.