4 ms·
I'll admit that I like Go channels because Hoare was the professor when I was doing my doctorate and so CSP was what I used in my thesis[1], but it's worth unde
by jgrahamc 2y ago
I'll admit that I like Go channels because Hoare was the professor when I was doing my doctorate and so CSP was what I used in my thesis[1], but it's worth understanding what unbuffered channels give you: it's message passing with synchronization. They are very simple to reason about and make writing concurrent code a breeze.
[1] https://blog.jgc.org/2024/03/the-formal-development-of-secure.html https://blog.jgc.org/2024/03/the-formal-development-of-secur...
- bsaul 2y agoi like the pattern, but message passing where the message is actually just a pointer to a mutable struct ( as allowed in go) kind of defeat the purpose, doesn't it ?
- superb_dev 2y agoIt kinda does yeah, you probably shouldn’t do that
- adastra22 2y agoIt’s fine if that’s the only (writable) pointer to the struct. Which is something go doesn’t enforce, but Rust does. I often dream of Go with Rust’s borrow checker. Sigh…
- dgb23 2y agoNo, it’s an idiomatic way of expressing who’s in charge of a given piece of data. There’s nothing in the type system preventing data races. But that’s orthogonal to channels. They just help you to structure the code.
- bjoli 2y agoI come from the complete opposite side: I have been writing some concurrentML code in guile scheme recently, and it has really made me understand why I always disliked go's channels. There are just so many things that are just slightly wrong to make it unpleasant. Better than many other things, but still kind of frustrating. I really think unbuffered channels should have been the default.