3 ms·

Channels and `async/await` are orthogonal. Channels are a way of communicating and coordinating between concurrent tasks; `async/await` are an alternative to bl

Channels and `async/await` are orthogonal. Channels are a way of communicating and coordinating between concurrent tasks; `async/await` are an alternative to blocking function calls (or an alternative form of blocking function calls, perhaps). There are implementations of channels for environments with `async/await`, where you would use syntax like `value = await channel.receive()`. What you may be getting at is that in an environment like Node.js, where everything runs in a single OS thread and there is no parallelism, there's a reduced need for coordination features like channels (or mutexes), because it's safe to mutate shared memory. But that too is orthogonal to `async/await`: the Python library gevent, for example, uses ordinary blocking function calls while running concurrent code in a single OS thread, making it safe to mutate shared memory; and conversely, C# allows `async/await` to be executed across multiple OS threads, making it unsafe to mutate shared memory.

hot_gril 2y ago
What I mean is, to do the equivalent of async/await in Golang, you need to use channels. As I understand it, you can wait on a goroutine to finish by waiting on its channel to return something. Async/await would simply be syntactical sugar on top of that, it's already close. One implication of async/await is that you need some kind of greenthreading or thread pool because you really don't want to spawn OS threads for it. In JS it's an event loop, Python and (I think) Rust have that too now as a lib, and Golang already has its own greenthreads. And btw, the reason JS doesn't have threading is because for those applications, you don't need fast communication between parallel tasks like the things Golang is made for. NodeJS supports subprocessing, and the tasks will probably not talk to each other at all, though there's IPC if you really want it.
- lenkite 2y ago
  You don't need to always use channels in Go. You can use the facilities of the sync package (https://pkg.go.dev/sync https://pkg.go.dev/sync) to communicate across go-routines.

hot_gril 2y ago

What I mean is, to do the equivalent of async/await in Golang, you need to use channels. As I understand it, you can wait on a goroutine to finish by waiting on its channel to return something. Async/await would simply be syntactical sugar on top of that, it's already close. One implication of async/await is that you need some kind of greenthreading or thread pool because you really don't want to spawn OS threads for it. In JS it's an event loop, Python and (I think) Rust have that too now as a lib, and Golang already has its own greenthreads. And btw, the reason JS doesn't have threading is because for those applications, you don't need fast communication between parallel tasks like the things Golang is made for. NodeJS supports subprocessing, and the tasks will probably not talk to each other at all, though there's IPC if you really want it.

lenkite 2y ago
You don't need to always use channels in Go. You can use the facilities of the sync package (https://pkg.go.dev/sync https://pkg.go.dev/sync) to communicate across go-routines.