4 ms·
really interesting to see that go channels weren't used due to performance concerns. channels is the often advocated tech for concurency in this language so hav
by bsaul 11y ago
really interesting to see that go channels weren't used due to performance concerns. channels is the often advocated tech for concurency in this language so having to fall back to mutexes seems like a downpoint. I would have loved to see a benchmark in the article.
- pcwalton 11y agoThis is very common. Sharing memory is extremely important whenever you're doing anything related to CPU parallelism/concurrency; often if you don't use it you end up worse than the sequential algorithm.
- haberman 11y agoIt's surprising to hear you say this. I thought a design goal of Rust was highly discouraging shared-state concurrency. Has this design philosophy evolved somewhat over time?
- tyoverby 11y agoRust has very good support for shared-state concurrency. In fact, the borrow-checker is used to enforce invariants about locks and mutices that make shared-mutable-state a compile-time error.
- doomrobo 11y agoNot at all. Rust gives programmers the ability to use shared state or channels at their discretion. The traits Send and Sync were made specifically for these use cases. Rust just guarantees that you can't use these primitives in an unsafe way.
- pcwalton 11y ago> Has this design philosophy evolved somewhat over time? Yes, it has. Post-1.0 Rust's design philosophy is about taming shared state concurrency: that is, disallowing data races statically, making sure you take locks or use atomics where possible, and having a robust set of generic concurrent data structures ready for use so you don't have to implement your own. This article, for example, rightly observes that atomics are difficult to get right, making it not scalable to have every program implement concurrent data structures from scratch. The benefit of having a rich set of generic concurrent data structures readily available is that it mitigates this problem.
- haberman 11y agoMakes sense! It's definitely a compelling story to offer the same abstractions that exist in other languages, but with static guarantees of correctness. A mutex that you can't mess up, that's a great thing.
- aaronbee 11y agoWhen it comes to accessing shared data it's often much simpler and more efficient to use a lock to protect that data. Channels are good in other scenarios.
- paulsutter 11y agoI wrote an HLS video proxy as my first go project last summer using only channels and goroutines. In retrospect it was clear that channels were very elegant for certain parts of the code, and in other areas mutexes would have been simpler. After a bit of experience with go, you gain an intuitive sense for which is appropriate in each case.
- kasey_junk 11y agoChannels are "just" mutexes as well. They are also not very fine grained because they have to deal with the general case. You can get much more precise writing your own locking code in Golang.
- cdelsolar 11y agoThe sync package's RWMutex is perfect for this problem. It will perform faster than channels and is much easier to reason about. Since it can support multiple simultaneous reads and one write the performance impact of a lock is minimal.