3 ms·
Yeah, C# await/async is cool. But isn't Google Go's approach nicer? Keep standard lib calls blocking as is, and use the "go" statement when you want to run some
by benhoyt 13y ago
Yeah, C# await/async is cool. But isn't Google Go's approach nicer? Keep standard lib calls blocking as is, and use the "go" statement when you want to run something async? It avoids all the extra DoWhateverAsync() API functions. See http://stackoverflow.com/a/7480033/68707 http://stackoverflow.com/a/7480033/68707
What's the Go equivalent of "await"? I.e., like the "go" statement but asynchronously wait for the function to return and get its value?
- chaosphere2112 13y agoci := make(chan int) go func(ci) <-ci
- carbocation 13y agoIf you're using `ci` as just a semaphore, you should use a struct, since those use even less memory than an int in go.
- carbocation 13y agoI think that WaitGroups or possibly just reading from a semaphore channel might do the trick for you in go.
- skybrian 13y agoThe difference is that Go has what looks like preemptive scheduling for goroutines (and will eventually be truly preemptive; see [1]) while await is more like cooperative multitasking. If you're writing in Go, you should use channels (or mutexes) to avoid race conditions: "share by communicating". With a single-threaded language using await, it's safer to modify common data structures without locks, although you should be aware that calling a function via "await" gives others task the opportunity to modify your data. So "await" appearing in the code explicitly warns you that pseudo-multitasking is happening. In Go, preemption can (in theory) happen at any time, plus there are multiple threads. [1] http://honnef.co/posts/2013/08/what_s_happening_in_go_tip__2013_08_15_/ http://honnef.co/posts/2013/08/what_s_happening_in_go_tip__2... Edit: Go isn't truly preemptive in 1.1.
- deleted 13y ago[deleted]