Any time you're dealing with multiple control paths (regardless of if they are real threads, logical threads, callbacks, asynchronous messaging, etc), small cha

Any time you're dealing with multiple control paths (regardless of if they are real threads, logical threads, callbacks, asynchronous messaging, etc), small changes in timing or synchronization will introduce non-determinism. For example, you don't know how quickly a remote service is going to respond. If you had some code that communicated with channels and used only a single real thread without using any non-deterministic operations, then you'd actually have deterministic choice. So if you write a unit test with some mock services, you would always read from a particular service because the execution is truly deterministic. That might also mean that if two services respond at similar times (even non-deterministically) and you prefer one over another in at a choice, you could wind up unfairly ignoring one of the channels. To combat this issue, Golang & core.async introduce randomness when multiplexing. If two channels are both ready, one is selected at random.