The first task is writing to the second when it's done with a computation, but not bothering to check input from the second while it's in the middle of a computation.
Well, this works as long as you're using a separate goroutine and the Go runtime creates more than one thread, right? My claim is that a Go runtime that only creates one thread (which is effectively what Joy is) will not work the way you expect in this case.
Or, more specifically, that if you have N goroutines that consist of infinite loops of pure computation (or really, anything that doesn't involve receiving from a channel), and at least one other goroutine that's receiving from a channel, your runtime needs to generate at least N+1 OS threads or your last goroutine will never get scheduled.
That isn't any different from anything else in the browser though. It's not going to lock up anymore than async JS code would during CPU intensive operations. Which generally don't need to be done in browsers anyways.
(Maybe I'm wrong and Go handles this smoothly?)