3 ms·
Yeah, I don't like Go in most respects, but their approach to concurrency is way more intuitive than async/await. That said, Go doesn't have any standard promis
by gambler 5y ago
Yeah, I don't like Go in most respects, but their approach to concurrency is way more intuitive than async/await. That said, Go doesn't have any standard promise or futures libraries, which is quite ridiculous. Yes, you can roll your own or go get one, but that is something basic should be in the language.
- Jtsummers 5y agoAs someone who has never really used promises or futures, what do they add, or how do they make concurrent programming easier or clearer than what's currently in Go?
- gambler 5y agoIn short, they provide clean API for checking on completion and error states of a long-running process from another thread without blocking that thread. This is an essential pattern for UI-related tasks, including web pages.
- Jtsummers 5y agoFair enough, I think we are thinking of futures slightly differently. I was thinking primarily about the deferred action to get a result (in which case channels and goroutines are equivalent with a select to handle, perhaps, an error result). You're also thinking of the other capabilities around task management and monitoring which I was not.
- phamilton 5y agoAn easy example of where having promises is nice: a := getFoo() b := getBar() c := getBaz() If you want to do all 3 in parallel, you may need to use channels and wait groups and stuff. In a language with promises: const a = getFoo(); const b = getBar(); const c = getBaz(); await a await b await c or even better const [a,b,c] = await Promise.all([getFoo(), getBar(), getBaz()]) If/when go generics become available, I expect to see some libraries that make things easier in golang.
- kevingadd 5y agoThis is built into the .NET API though? You can just check the Faulted and Completed properties of the Task you're holding.
- Jenk 5y agoGP wants those to be part of the Go stdlib.