Disclaimer: I've been a Go programmer for ~9 years and think that Promises and to a lesser extent, async/await, are inferior to Go's native concurrency primitives... so for all intents and purposes, I am making this comment from my high horse and I apologize if this sounds overly negative - I don't indent for it to sound that way.
With that said, IMO, this doesn't seem to be any better than channels.
For all examples, you can use a single channel or no concurrency. And for that you reduce complexity, remove the need for error handling and don't throwing away type-safety.
EDIT: I didn't read WHY.md because it looked way too long and wordy for something as simple as this, so take my comment with a few more grains of salt.
The points you raised are why I wrote WHY, but I'll do my best to summarize the weaknesses of channels+goroutines that I believe this covers:
- fan out, because channels don't support it
- error chaining between goroutines. The solution I've often seen here is an error channel and another way of cancelling workers. If an early promise returns an error, later promises won't execute and the early error will get returned on Wait()
- complex graphs of async operations that are only executed once
re: type safety: this library will make sure all your types line up before executing your functions. With generics/contracts it may be eventually possible to make it compile time safe as well.
3 comments
[ 2.8 ms ] story [ 16.6 ms ] threadrepo: https://github.com/garlicnation/promises
godoc: https://godoc.org/github.com/garlicnation/promises
With that said, IMO, this doesn't seem to be any better than channels.
For all examples, you can use a single channel or no concurrency. And for that you reduce complexity, remove the need for error handling and don't throwing away type-safety.
EDIT: I didn't read WHY.md because it looked way too long and wordy for something as simple as this, so take my comment with a few more grains of salt.
The points you raised are why I wrote WHY, but I'll do my best to summarize the weaknesses of channels+goroutines that I believe this covers:
- fan out, because channels don't support it
- error chaining between goroutines. The solution I've often seen here is an error channel and another way of cancelling workers. If an early promise returns an error, later promises won't execute and the early error will get returned on Wait()
- complex graphs of async operations that are only executed once
re: type safety: this library will make sure all your types line up before executing your functions. With generics/contracts it may be eventually possible to make it compile time safe as well.