[rust-dev] Why focus on single-consumer message passing?

Daniel Micay danielmicay at gmail.com
Sat Jan 25 02:48:31 PST 2014

On Sat, Jan 25, 2014 at 5:37 AM, Jeremy Ong <jeremycong at gmail.com> wrote:
>> Rust should be providing the building blocks for a concurrency pattern
>> determined by the needs of the application. I don't think it should
>> push a specific design, as there are many ways of doing this with
>> their own merits.
> There is a spectrum of flexibility and safety. I'll be honest, if given a
> 10000 LOC
> highly concurrent application to work with, I'd feel much more comfortable
> if things were
> primarily shared nothing and it was hard to abuse error-prone shared memory
> issues
> (race conditions, deadlock, etc). Those problems are even possible in CSP
> systems
> but at least they're easier to identify and eliminate. It could be argued
> that if all you
> want are primitive build blocks in a systems language, it already exists in
> C.

Rust aims to be a systems language displacing C and C++ from their
niche. I don't think it's suitable as one with the standard library,
and it's not replacement for C without a large library ecosystem.

I doubt it's really any easier to avoid race conditions with channels
as opposed to concurrent data structures, whether they are persistent
or mutable. Keep in mind that Rust won't let you have data races
whether or not you are sharing data.

> As an aside, I like the distinction in Haskell between threads (parallelism
> units mapped
> to cores) and par/pseqs (green concurrency units). Rust tasks feel more like
> a library
> feature to me rather than a systems feature. Perhaps a much more flexible
> systems-oriented threaded model is better suited for a primitive more
> analogous to
> the pthread?

Rust doesn't have segmented stacks anymore so it's not going to have
low memory usage synchronous I/O units. Tasks are pretty much just a
lossy abstraction over threads.

More information about the Rust-dev mailing list