> Something I miss from the language …

Does sound like you want to use channels, and break your logic into small independent parts.

You will have one goroutine using blocking Read() in a loop and feeding data to some channel. When it's done, you write to another channel that exists only for signaling:

    defer {
      doneChannel <- true
    }
    for {
      data := make([]byte, 65535)
      _, err := conn.Read(data)
      if err != nil {
        errorChannel <- err
        break;
      }
      dataChannel <- data
    }

and then in your other goroutine:

    for {
      select {
        case data := <- dataChannel:
          // Handle data
        case <- doneChannel:
          // Other goroutine is done
      }
    }

The only things shared here are the channels.

The way to avoid too much state and moving parts is to break the problem into isolated, manageable parts that communicate with channels. Often you will have hierarchical relationships like this, where one piece of dumb code exists to pass data from something lower down to somewhere higher up.

It's not hard, although some of the code gets a bit ugly and disjoint at times, especially in how anything synchronous has to use channels and goroutines. For example, today I wrote a simple worker pool implementation that runs a given function in parallel via goroutines and can adjust the number of workers dynamically at runtime. That function has to be declared not just as "func()" but as "func(abortChannel chan bool)", and the worker function has to honour the abort signal when it arrives from the pool. So channels do leak everywhere, even into APIs. (Yeah, I know I can use "chan struct{}" to avoid any storage, but I think "<- true" looks nicer than "<- struct{} {}".)

What is harder is to intelligently handle complex cascading failures. That's what Erlang, with its supervisor tree, is good at. Go's goroutines are "fire and forget" and cannot even be terminated programmatically from elsewhere in the program.