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 <mirtchov...@gmail.com> 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.fal...@gmail.com> > 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+unsubscr...@googlegroups.com. > > 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. > -- 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.
