Edit: The CS course I did in the 1980s had a Concurrent Programming course that covered CSP and another one of my favourites: Petri Nets
Edit2: Go also has concurrency features influenced by CSP:
The end goals of both languages are mostly the same, but while CSP aims at being a "powerful" language, CCS strives for simplicity. You can see how both approaches have their pros and cons.
Can you write more about the programming experience? Particularly the handling parallel processes and communication, but also general observations.
One concept we explored was using CSP as a 'formal backbone' that handled communication/parallelism in complex systems while allowing stand-alone 'business logic' to co-exist without the need for the same level of rigour.
If you're reasoning about a concurrency problem, doing a quick CSP spec on the back of an envelope is a great way to 'check your math.'
Steve Schneider's book is a very approachable text on the subject: https://www.amazon.ca/Concurrent-Real-time-Systems-CSP-Appro...
That book has been made availabel for free as a PDF.
I really enjoyed playing with this library. Somehow the basic abstractions and the mental model to use it felt much easier in general than the threading model. It reminded me of go channels for some extent. It is also a very powerful concept. It even allows to emulate the actor model. Sadly it is not actively developed any more.
Go channels explicitly drew from CSP for inspiration, but it is not exactly the CSP in the paper.
That said, almost everything that draws from CSP for inspiration has at least a small difference from the paper, if you analyze it closely enough. Often major differences. The idea seems robust enough to those variations that it's not a problem, though.
If anyone wants to learn something from CSP, learn why it doesn't work.
The history of programming shows a lot of evidence that good ideas can take decades from initial proposal to even being in a B-list language like Go, let alone being "widely used" to the degree I think you are, so I put only modest credence in it being not terribly widely used yet.
"And Go itself is constantly fighting CSP deficiencies, trying to abstract it away and move closer to actors."
Having programmed in Erlang for a long time, I don't find this to be true. I've certainly got quite a few things that look like actors, but quite a lot of things that definitely aren't, too.
"CSP alone cannot be used for anything real world related"
Which probably goes back to why everyone tends to tweak it a bit. (I have further quibbles with that characterization, but not important enough to go into.) And Go doesn't offer "CSP alone", but rather CSP grafted on to the side of a standard structured programming model, something we do know can be used for real-world work, so it all seems to work out pretty well.
Clojure’s core.async is another arguably widely used implementation (it pays my bills).