[AtroxDev]

From Rob Pike on reddit regarding this post[0]:

The and and or functions in the template packages do short-circuit, so he's got one thing already. It was a relatively recent change, but it's there.

Non-deterministic select is a critical detail of its design. If you depend on a deterministic order of completion of tasks, you're going to have problems. Now there are cases where determinism might be what you want, but they are peculiar. And given Go's general approach to doing things only one way, you get non-determinism.

A shorthand syntax for trial communication existed. We took it out long ago. Again, you only need one way to do things, and again, it's a rare thing to need. Not worth special syntax.

Some of the other things mentioned may be worth thinking about, and some of them have already (a logging interface for instance), and some we just got wrong (range). But overall this seems like a list of things driven by a particular way of working that is not universal and discounts the cost of creating consensus around the right solutions to some of these problems.

Which is not to discount the author's concerns. This is a thoughtful post.

0: https://old.reddit.com/r/golang/comments/s58ico/what_id_like...

[dewey]

> 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.

[nightowl_games]

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

[cle]

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

[tapirl]

> 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).

[uluyol]

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

[usrbinbash]

> Not vice versa (the current design).

    select {
       case: <-chan1_whichIWantToCheckFirst
       default:
    }

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

[tapirl]

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

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

[usrbinbash]

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

[tapirl]

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

[usrbinbash]

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.

[morelisp]

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

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

[tapirl]

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

[rplnt]

> 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?

[tapirl]

> > 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.

[morelisp]

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

[tapirl]

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.

[lanstin]

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

[tapirl]

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.

[lanstin]

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.

[tapirl]

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.

[lanstin]

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.