In an implementation that follow's Go's semantics, both reading and writing from a channel can be a blocking operation that causes the current "thread" to suspend until the channel is ready to receive or provide a value.

That in turn means you need to compile it to something like the CSP-transformed JS you use for async/await. It's not just a little bit of sugar for a method call. The compiler needs to be aware of it so it can transform the code appropriately.

However, from looking at the code, it looks like spider currently only does this for channel reads. Writes are always non-blocking, which limits their usefulness.

Function calls can block the thread too. Parent was questioning the need for the programmer to have a different syntactical interface to channels.