> Again, you only need one way to do things, and again, it's a rare thing to need. Not worth special syntax.

This really is one of the parts I like the most about Go. It really makes so many things simpler. Discussing code, tutorials and writing it.

Every time I'm trying to do something in JS I have to figure out why every guide has a different way of achieving the same thing and what are the implementation differences.

It'd be nice if he had at least hinted towards what 'the way' is for this problem.

It’s in the article he’s responding to.

> but (deterministic-select cases) hey are peculiar.

It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or deterministic.

But, if the default is deterministic, user code could simulate non-deterministic, without much performance loss. Not vice versa (the current design).

Er, when it comes to concurrency, non-determinism is usually cheaper than determinism. As soon as you care about ordering, you almost always have to synchronize, and that has a cost.

Austin Clements (of the Go runtime team) wrote a paper that explores this in detail [1]. That was before joining the Go team, but the concepts are universal.

[1] https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf

> Not vice versa (the current design).

    select {
       case: <-chan1_whichIWantToCheckFirst
       default:
    }

    select {
       case: <-chan2_whichItreatTheSameAsChan3
       case: 0xFF ->chan3_whichItreatTheSameAsChan2
    }

Yes, as I have mentioned, there is performance loss, comparing to

    select {
       case: <-chan2_whichItreatTheSameAsChan3 // a higher priority
       case: 0xFF ->chan3_whichItreatTheSameAsChan2
    }

The real usecases where I need deterministic select, are so few that a small performance loss doesn't matter to me.

Sometimes, it is not related to performance loss, it is related to implementation cleanness and complexity.

A separate `select` with empty `default` is about as simple and clean as it gets. It is easy to read, easy to reason about, and, most importantly, conveys the intention of the code perfectly.

1) Is there really a performance loss compared to if select was deterministic?

2) What in the world do you need such code for?

1) surely.

2) just read:

     https://groups.google.com/g/golang-nuts/c/SXsgdpRK-mE/m/CT7UjJ3aBAAJ

     https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o

     https://groups.google.com/g/golang-nuts/c/lEKehHH7kZY/m/SRmCtXDZAAAJ

> user code could simulate non-deterministic

I'm curious how?

> Not vice versa

There are pretty common patterns for this. At least for real word cases where you might have one special channel that you always want to check. Ugly, but in relation to the previous question, I don't see how one is doable and one isn't?

> > user code could simulate non-deterministic

> I'm curious how?

    if rand.Intn(2) == 0 {
        select {
           case: <-chan2_whichItreatTheSameAsChan3 // a higher priority
           case: 0xFF ->chan3_whichItreatTheSameAsChan2
        }
    } else {
        select {
           case: 0xFF ->chan3_whichItreatTheSameAsChan2 // a higher priority
           case: <-chan2_whichItreatTheSameAsChan3
        }
    }

Yes, it increases verbosity to the other way, but no performance loss.

How in the world is generating a random number and branching and doubling the number of instructions "no performance loss"?

Now the non-deterministic implementation does more work than a deterministic implementation. It generates a random number and sorts the branches. The latter (sorts the branches) is not needed in the above pseudo code.

Doubling the number of instructions has no impact on run-time performance.

And there are more optimization opportunities in implementing a deterministic design. Now, the non-deterministic implementation needs to lock all involved channels before subsequent handling, a deterministic implementation might not need to.

Any time there is more than one channel being selected for it needs to cover them all equally.

Equality is meaningful only if at least two case operations are always non-blocking. This is rare in practice.

In fact, in practice, sometimes, I do hope one specified case has a higher priority than others if they are all non-blocking.

As far as priority goes, most interesting cases will have priority based on the data in the read, except for this specific case of a done chan el and a data channel. I used that pattern at first but have been moving away from it. To be sure i am mostly writing long lived processes with fixed pools of worker go routines and either never exit or exit based on WaitGroups determining the work is all done.

Yes, it (the lack of deterministic-select) is only annoying for several special cases. For most cases, it doesn't matter whether or not the default behavior is deterministic.

Wouldn't it be the case id one worker was pulling work asynchronously delivered from two places? I only use one go routine / one channel myself, but the name select itself very strongly implies it is a yield type operation where any of a number of async actions can wake it for their callback to run. Albeit without a callback syntax, it is async and better be fair.