[q3k]

Not great as is.

Rust does not have a comprehensive story for CSP concurrency like Go has. It does have a fair share of libraries/ecosystems (like Tokio), but not having something built in means that you have to hunt for the right set of libraries to work together. Meanwhile, in Go, every single library will just work with its concurrency model out of the box.

[alexeldeib]

I write in Go daily and I've been ramping up on Rust. While CSP isn't built into the language, Crossbeam, Flume, and others are more than enough to fill the gap.

If anything, I find Rust returns flexibility to me in programming choice that Go made me forget I had. There are places where library support in Go is still richer, but language support has been stellar across the board in Rust.

[throwaway894345]

I write Go daily, and I don't think CSP really panned out. For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP. That might be an artifact of how channels are implemented and their many hidden error cases--perhaps a better channel implementation could change the calculus. There are lots of reasons to prefer Go to Rust IMO, but I don't think CSP is among them.

[dnautics]

> For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP

It's easier to write code with standard threading tooling but I think CSP is much, much easier to debug and avoid deadlocks.

[morelisp]

> I think CSP is much, much easier to debug and avoid deadlocks.

This has (still to my surprise) not borne out in real-world cases, at least to the extent Go channels "do CSP".

https://blog.acolyer.org/2019/05/17/understanding-real-world...

[throwaway894345]

That has not been my experience with CSP via Go channels after 8 years of solid use (I still use channels here and there, but not in a CSP pattern). Different strokes, I suppose.

[asimpletune]

Rust has channels though, unless I misunderstand what you mean.