Axel, thank you. Big heartfelt thanks. You really understand me. My respect to you.
вторник, 18 октября 2016 г., 11:55:40 UTC+3 пользователь Axel Wagner написал: > > Not all of them are wrong (in fact, almost none of them are). They just > don't do everything and anything you could ever choose to want from an > implementation so they appear unsatisfactory. > > Which, in the long list of issues that have been presented and remain > unaddressed in regards to this proposal, adds another one: Writing one > implementation that covers every use case you could ever have for them > efficiently is, indeed, hard and error-prone. Whereas covering any specific > use case with channels takes only a small handful of lines of trivial code. > > On Tue, Oct 18, 2016 at 10:17 AM, andrey mirtchovski <mirtc...@gmail.com > <javascript:>> wrote: > >> as a person happy to remain willingly ignorant of promises and futures >> i notice from the sidelines that the concepts seem to lack clarity and >> vision. if five different implementations got them wrong there will be >> five different people wondering why the stdlib one isn't working >> right. that's five too many. >> >> On Tue, Oct 18, 2016 at 2:10 AM, Sokolov Yura <funny....@gmail.com >> <javascript:>> wrote: >> > Roger >> > >> >> If you want to make it possible, it's pretty easy: >> > https://play.golang.org/p/YWYFSL2QTe >> > >> > Thank you for fifth copy of almost same code. I clearly have no enough >> experience to use close of channel and `sync.Once`. >> > Do you really think so? >> > >> >> There's another idiom I quite like for futures (when there's only one >> > possible source of the value) putting the value back after >> > taking it out: https://play.golang.org/p/_7p69KE_RZ >> > >> > And that is really broken idiom. It has race condition: concurrent >> goroutine may put dufferent value in the channel between those two lines of >> code. More over, if you use blocking send here, then you will end in >> blocked goroutine in this case. >> > Another mistake in this idiom: if other concurrent goroutine checks >> this channel within select, and that check happens between those two lines >> (between receive and following send), then it see empty "future". >> > And even ir when does not lead to mistake, it serialize "broadcast": >> goroutines are awoken one after other, instead of being awoken in parallel. >> > >> > That is why I want language (or standard library) to have reliable >> implementation: people should not invent bicycles with square wheels. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "golang-nuts" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to golang-nuts...@googlegroups.com <javascript:>. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
