Problems with Go channels (2016)

Go user for ten years and I don’t know what happened, but this year I hit some internal threshold with the garbage type system, tedious data structures, and incessant error checking being 38% of the LoC. I’m hesitant to even admit what language I’m considering a full pivot to.

As you mentioned "improvement of existing language," I'd like to mention that Haskell has green threads that most probably are lighter (stack size 1K) than goroutines (minimum stack size 2K).

Haskell also has software transactional memory where one can implement one's own channels (they are implemented [1]) and atomically synchronize between arbitrarily complex reading/sending patterns.

[1] https://hackage.haskell.org/package/stm-2.5.3.1/docs/Control...

In my not so humble opinion, Go is a library in Haskell from the very beginning.

I'm guilty of this too https://github.com/PeerDB-io/peerdb/blob/d36da8bb2f4f6c1c821...

The inner channel is a poor man's future. Came up with this to have lua runtimes be able to process in parallel while maintaining ordering (A B C in, results of A B C out)

I have a channel for my gRPC calls to send work to the static and lock free workers; I have a channel of channels to reuse the same channels as allocating 40k channels per second was a bit of CPU. Some days I am very pleased with this fix and some days I am ashamed of it.

You joke, but this is not uncommon at all among channels purists, and is the inevitable result when they try to create any kind of concurrency abstractions using channels.

Ugh... I hope I never have to work with channels again.

I almost always only use Channels as the data path between fixed sized pools of workers. At each point I can control if blocking or not, and my code uses all the (allocated) CPUs pretty evenly. Channels are excellent for this data flow design use case.

I have a little pain when I do a cli as the work appears during the run and it’s tricky to guarantee you exit when all the work is done and not before. Usually Ihave a sleep one second, wait for wait group, sleep one more second at the end of the CLI main. If my work doesn’t take minutes or hours to run, I generally don’t use Go.

AND because they're usually hidden as implementation detail, a consumer of your module can create simple mocks of your module (or you can provide one)

How many developers did that scale to? Code bases that I’ve seen that are written in that style are completely illegible. Once the structure of the 30 node graph falls out of the last developer’s head, it’s basically game over.

To debug stuff by reading the code, each message ends up having 30 potential destinations.

If a request involves N sequential calls, the control flow can be as bad as 30^N paths. Reading the bodies of the methods that are invoked generally doesn’t tell you which of those paths are wired up.

In some real world code I have seen, a complicated thing wires up the control flow, so recovering the graph from the source code is equivalent to the halting problem.

None of these problems apply to async/await because the compiler can statically figure out what’s being invoked, and IDE’s are generally as good at figuring that out as the compiler.

To me message passing is like it's own thing. It's the most natural way of thinking about information flow in a system consisting of physically separated parts.

What you think is not very relevant if it doesn't match how CPUs work.

At least historically, google engineers had 20% of their time to spend on projects not related to their core role

Google historically allowed employees to self-direct 20% of their working time (onto any google project I think).

I assume this means "20% of my work on go" aka 1 out of 5 work days working on golang

Rob Pike was definitely not a PL expert and I don’t think he would claim to be. You can read his often-posted critique of C++ here: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

In it, he seems to believe that the primary use of types in programming languages is to build hierarchies. He seems totally unfamiliar with ideas behind ML or haskell.

I guess we're going into the definition of the word "expert".

I don't think the word encompasses "have done it several times before, but has not actually even looked at the state of the art".

If you're a good enough engineer, you can build anything you want. That doesn't make you an expert.

I have built many websites. I'm not a web site building expert. Not even remotely.

This is optics versus reality. Its goal was to address shortcomings in C++ and Java. It has replaced neither at Google and its own creators were surprised it competed with python, mostly on the value of having an easier build and deploy process.

I would say this is another thing that would take quite a while to flesh out. Not only is it hard to have this conversation in text-only on hackernews, but HN will also rate limit replies, so a conversation once started cannot continue here to actually allow the discussion participants to come to an understanding of what the they all mean. Discussion will just stop once HN tells a poster "you're posting too often".

Hopefully saving this comment will work.

Go, unlike Brexit, has pivoted to become the solution to something other than its stated target. So sure, Go is not a failure. It was intended to be a systems language to replace C++, but has instead pivoted to be a "cloud language", or a replacement for Python. I would say that it's been a failure as a systems language. Especially if one tries to create something portable.

I do think that its simplicity is the rejection of the idea that there are experts out there, and/or their relevance. It's not decisions based on knowledge and rejection, but of ignorance and "scoping out" of hard problems.

Another long article could be written about the clearly not thought through use of nil pointers, especially typed vs untyped nil pointers (if that's even the term) once nil pointers (poorly) interact with interfaces.

But no, I'm not comparing the outcome of Go with Brexit. Go pivoting away from its stated goals are not the same thing as Brexiteers claiming a win from being treated better than the EU in the recent tariffs. But I do stand by my point that the decision process seems similarly expert hostile.

Go is clearly a success. It's just such a depressingly sad lost opportunity, too.

I think Java made many decisions that turned out to be bad only in retrospect. In Go we knew (well, experts knew) already that the choices were bad.

Java is a child of the 90s. My full rant at https://blog.habets.se/2022/08/Java-a-fractal-of-bad-experim... :-)

> I actually think Java is the better PL, but the worse runtime (in what world are 10s GC pauses ever acceptable).

This seems like a very odd/outdated criticism. 10s CMS full STW GCs are a thing of the past. There are low-latency GCs available for free in OpenJDK now with sub-millisecond pause times. Where I've seen the two runtimes compared (e.g. Coinbase used both langs in latency-sensitive exchange components) Java's has generally come out ahead.

The intersection of nil and interfaces is basically one giant counter-intuitive footgun.

Or how append() sometimes returns a new slice and sometimes it doesn't (so if you forget to assign the result, sometimes it works and sometimes it doesn't). Which is understandable if you think about it in terms of low-level primitives, but in Go this somehow became the standard way of managing a high-level list of items.

Or that whole iota thing.

I've found the smartest go engineer in the room is usually the one NOT using channels.

> I do use a lot the basic pattern of `loop { select! { ... } }` that manages its own state.

Care to show any example? I'm interested!

async mutexes?

> Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code.

> The feature that the async mutex offers over the blocking mutex is the ability to keep it locked across an .await point.

https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html

In both examples, the HandlePlayer for loop only exits if .NextScore returns an error.

In both cases, you’d need to keep track of connected players to stop the game loop and teardown the Game instance. Closing the channel during that teardown is not a hurdle.

What am I missing?

It’s not entirely clear whether the author is describing a single or multiplayer game.

Among the errors in the multiplayer case is the lack of score attribution which isn’t a bug with channels as much as it’s using an int channel when you needed a struct channel.

I don't think there's much trouble at all fixing the toy example by extending the message type to allow communication of the additional conditions, and I think my changes are better than the alternative of using a mutex. Have I overlooked something?

Assuming the number of players are set up front, and players can only play or leave, not join. If the expectation is that players can come and go freely and the game ends some time after all players have left, I believe this pattern can still be used with minor adjustment

(please overlook the pseudo code adjustments, I'm writing on my phone - I believe this translates reasonably into compilable Go code):

  type Message struct {
    exit bool
    score    int
    reply chan bool
  }

  type Game struct {
    bestScore int
    players int // > 0
    messages    chan Message
  }

  func (g *Game) run() {
    for message := range g.messages {
      if message.exit {
        g.players = g.players - 1;

        if g.players == 0 {
          return
        }
        continue
      }
  
      if g.bestScore < 100 && g.bestScore < message.score {
        g.bestScore = message.score
      }

      acceptingScores := g.bestScore < 100

      message.reply <- acceptingScores
    }
  }

  func (g *Game) HandlePlayer(p Player) error {
    for {
      score, err := p.NextScore()
      if err != nil {
        g.messages <- { exit: true
      }
      return err
    }
    g.messages <- { score, reply }
    if not <- reply {
       g.messages <- { exit: true }
       return nil
      }
    }
  }

I don't think channels should be used for everything. In some cases I think it's possible to end up with very lean code. But yes, if you have a stop channel for the other stop channel it probably means you should build your code around other mechanisms.

Since CSP is mentioned, how much would this apply to most applications anyway? If I write a small server program, I probably won't want to write it on paper first. With one possible exception I never heard of anyone writing programs based on CSP (calculations?)

Naive question, can't you just have a player count alongside the best score and leave when that reaches 0?

Haven't read the article but it sounds like a waitgroup would suffice.

My hot take on context is that it's secretly an anti-pattern used only because of resistance to thread locals. While I understand the desire to avoid spooky action at a distance, the fact that I have to include it in every function signature I could possibly use it in is just a bit exhausting. Given I could inadvertently spin up a new one at will also makes me a bit uneasy.

I'm also wondering about the internals though. There are a couple of places that GC and the hypothetical sufficiently-smart-compiler are called out in the article where you could think there might be improvements possible without breaking existing code.

> Do you have any benchmarks for the pattern you described where channels are more efficient?

https://go.dev/play/p/qXwMJoKxylT

go test -bench=.* -run=^$ -benchtime=1x

Since my critique of the OP is that it's a contrived example, I should mention so is this: the mutex version should be a sync.Atomic and the channel version should have one channel per goroutine if you were attempting to write a performant concurrent counter, both of those alternatives would have low or zero lock contention. In production code, I would be using sync.Atomic, of course.

On my 8c16t machine, the inflection point is around 2^14 goroutines - after which the mutex version becomes drastically slower; this is where I believe it starts frequently entering `lockSlow`. I encourage you to run this for yourself.

> Do you have any more details about this? Why isn’t sync.Mutex implemented with that same mutex channels use?

Why? Designing and implementing concurrent runtimes has not made its way onto my CV yet; hopefully a lurking Go contributor can comment.

The channel mutex: https://go.dev/src/runtime/chan.go

Is not the same mutex as a sync.Mutex: https://go.dev/src/internal/sync/mutex.go

If I had to guess, the channel mutex may be specialised since it protects only enqueuing or dequeuing onto a simple buffer. A sync.Mutex is a general construct that can protect any kind of critical region.

> What is the rule of thumb your Go shop uses for when to use channels vs mutexes?

Rule of thumb: if it feels like a Kafka use case but within the bounds of the local program, it's probably a good bet.

If the communication pattern is passing streams of work where goroutines have an acyclic communication dependency graph, then it's a no brainer: channels will be performant and a deadlock will be hard to introduce.

If you are using channels to protect shared memory, and you can squint and see a badly implemented Mutex or WaitGroup or Atomic; then you shouldn't be using channels.

Channels shine where goroutines are just pulling new work from a stream of work items. At least in my line of work, that is about 80% of the cases where a synchronization primitive is used.

And implying I don't understand toy examples and responding with this is apparently above the bar for serious discussion.

I have replied to another comment with more details: the channel mutex is not the same one that sync.Mutex is using.

The article that the OP article references does not show the code for their benchmark, but I must assume it's not using a large number of goroutines.

Thanks for the tip! Will definitely take into account your insights on channels if I decide to dive into it.