mozilla :: #rust-community

12 Aug 2017
13:03badboyaaaah shit, need to find some time for finishing the underhanded blogpost
15:07* fwiw yay underhanded
17:57badboyuuuuh I also now got a packt mail
17:58badboybut to a not-anywhere-used mail address oO
18:01* carols10cents whistles innocently
18:02badboycombined killercups response and mine asking for sponsoring :D
18:50killercupbadboy: naice
19:34stjepangI want to publish a blog post, titled "Everything wrong with std::sync::mpsc". Does anyone want to review it before I post it?
19:34stjepangPardon my writing skills - this would be my first blog post ever, so I'd be super thankful for any feedback! :)
20:34Manishearthstjepang: looking
20:35stjepangThank you!
20:35Manishearthstjepang: re: problem #2: Go has an analogue of this problem too
20:36Manishearthc := make(chan string) vs make(chan string, 1000)
20:36ManishearthIIRC the first is a single-element channel
20:36stjepangthe first is a zero-element channel, actually :)
20:37Manishearththis is never really explained well anywhere
20:37Manishearthi.e. sync_channel
20:37Manishearthstjepang: there is a satisfying answer. Sender and SyncSender use different abstractions under the hood (IIRC)
20:37Manishearthdifferent types = different optimizations
20:38Manishearthand while you paint channel vs sync_channel to be a minus point, this is one of the worst things in Go!
20:38stjepangIt might be a bit confusing that I'm criticising Rust's channel on both naming conventions and on technical merits. I'll probably move naming conventions to some kind of addendum, since that isn't meant to be the spotlight of the blog post.
20:38ManishearthI've TAd a course with Go, and *the main blunder* made by all the students was not using buffered channels because this isn't clear at all
20:38Manishearthyou *rarely* want buffered channels
20:38Manishearthchannel vs sync_channel is bad
20:39Manishearthwhere sync_channel is more obscure
20:39stjepangManishearth: Right, but from the standpoint of a user, it's just unfortunate. This is a leaky abstraction, right? :)
20:40stjepangI agree with you. Go and Rust are different languages with different idioms.
20:40Manishearthstjepang: *no*, that's my point
20:40Manishearthit's not a leaky abstraction
20:40Manishearthit's very important for them to be different
20:40Manishearth(a) it's important that the *default* is infinitely buffered. that's what you usually want
20:40Manishearth(b) it's important that folks understand when they pick a synchronous channel
20:41ManishearthGo fails at both these. the default is synchronous, which is *not* how most go code needs it
20:41Manishearthit's not clear that the channel you've picked is synchronous
20:41Manishearthchannel vs sync_channel is great for this
20:41Manishearththe naming "sync" is perhaps confusing, but having different channel types for this is agood thing
20:42Manishearthstjepang: what is wrong with Sender not implementing Sync?
20:42stjepangHmm. Perhaps I'm misunderstanding... But I think choosing channel() vs sync_channel(n) is enough. By choosing one of the two functions you make the choice. Why bother the user with the Sender/SyncSender split as well?
20:43stjepangManishearth: Here's whats wrong with that:
20:43Manishearthstjepang: sure that would be enough. but your post seems to convey Go's design decision as a good thing. it isn't, IMO
20:43stjepangI should really include this link :)
20:43Manishearthit's one of the annoying warts in go
20:43Manishearthstjepang: hm, fair
20:44stjepangFair enough, point taken.
20:44Manishearthstjepang: how is this a tragic ending? futures will be supporting this, yeah?
20:45Manishearthi think tokio has selection
20:45stjepangManishearth: It's tragic because Servo needs selection on std::sync::mpsc channels.
20:45stjepangServo won't switch to tokio.
20:46Manishearthstjepang: .....
20:46Manishearthstjepang: we are considering it actually
20:46stjepangOh wow. Any particular reason?
20:46Manishearthfor the network stack?
20:49ManishearthI do wish rust had mpmc though
20:49Manishearthspelling: *unergonomic
20:49Manishearthstjepang: overall i think this is a good post, but it muddles a few things
20:50Manishearthin particular the naming issue -- it portray's go's decision as a good one, whereas it's actually not great
20:50stjepangI'll do my best to improve it and go through another revision. Thanks a lot for reading it! :)
20:50Manishearthyou're right thathaving the same abstraction is a good thing
20:50Manishearthbut that's not the point the thing makes
20:50Manishearthso probably be more clear about that
20:51Manishearththen again buffered vs unbuffered is pretty different
20:51Manishearthyou see leaky abstraction, I see the typical minute control over details that rust tends to have
20:51Manishearthit's like calling Arc vs Rc a leaky abstraction, in one sense
20:53stjepangI don't think there's a good technical reason for the Sender/SyncSender split. I mean, they could've been conflated to a single Sender without losing anything.
20:56Manishearthstjepang: really?
20:57ManishearthSender is infinitely buffered. SyncSender is not. That's a pretty major difference
20:57Manishearthone can block , one never will
20:57Manishearthrust has a lower affinity to runtime abstraction
20:58Manishearthagain, the same argument can be made for merging Rc and Arc and keeping a flag
20:58Manishearthhuh, that has changed
20:58stjepangHere, every method in Sender matches on the flavor and simply has `unreachable!()` for the sync variant. :) So it's all there. :)
20:58Manishearthstjepang: sure. my other argument still stands. rust prefers having contracts in the types
20:58Manisheartheven if there's no runtime cost to merging them
21:00stjepangWell, that certainly makes sense. But I also personally think it's a rather weak reason for the split. shrug
21:00stjepangIn any case, will take this into consideration when rewriting the text.
21:01Manishearthanyway this part is a matter of difference of opinion, which is fine, put whatever opinion you want in the post
21:01Manishearthbut be super clear about *what* exactly you like about go here and what you would prefer rust's channels to be like
21:02Manishearthlet x = channel() vs let x = sync_channel(x) is a good way to put it as you already did
21:02stjepangwill do!
21:02Manishearthi.e. you want the types to be the same
13 Aug 2017
No messages
Last message: 8 days and 23 hours ago