10 ms·
> To have an abstraction where you really don't care about blocking or not you need promises/futures. Go's futures are bad. Real bad. Please explain.
by fooster 11y ago
> To have an abstraction where you really don't care about blocking or not you need promises/futures. Go's futures are bad. Real bad.
Please explain.
- kasey_junk 11y agoWell it's possible I over stated the necessity for futures as their might be other abstractions that allow you to compose concurrent/non-concurrent systems in a way that is transparent to the api. Its just one of the easier ones to reason about. That said, I don't believe concurrency should be transparent to the api, rather it should be front and center to it. As for the go futures being bad, channels generally are a bad concurrent queue (contended, lack basic abstractions, etc) and using a single item queue as a future isn't in and of itself bad, but does mean you can't optimize for different usages that futures might have over message passing queues.