4 ms·
async/await is just syntax. There's nothing saying that two async calls can't run fully in parallel. "Blocking" is subjective too; in a way even JS is doing som
by hot_gril 2y ago
async/await is just syntax. There's nothing saying that two async calls can't run fully in parallel. "Blocking" is subjective too; in a way even JS is doing some parallelism.
- bruce343434 2y agoI covered my ass: > async/await (as most commonly implemented) Javascript is famously single threaded, which is probably the runtime on which most async/await code runs today. But yes, Rust for instance has the Tokio async runtime which is parallel, although it also has cooperative async runtimes. For those who are reading this and feeling unsure: Go has parallel execution, and it calls `fork()` `go`. Go doesn't feature a `join()`, for that you must use channels: func main() { done := make(chan bool) go func() { fmt.Println("goroutine running") time.Sleep(2 * time.Second) // simulate some work done <- true }() <-done fmt.Println("goroutine finished") } Funny thing: if you have a goroutine which is waiting to receive some value from a channel, but it never does this, and the other handles to the channel are gone, you get a goroutine leak! The goroutine is blocked, and unrecoverable/unkillable.
- kfajdsl 2y agoI mean, the top comment wasn't talking about runtime characteristics, they were talking about the patterns resulting from using co-routines with messaging vs async/await.
- deleted 2y ago[deleted]
- hot_gril 2y agoThat's right. So if Golang wanted to do async/await, it would probably be in a fully parallel way.
- fmbb 2y agoIsn’t a WaitGroup a more common way to do join? https://pkg.go.dev/sync#WaitGroup https://pkg.go.dev/sync#WaitGroup