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

[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
    }

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

[lanstin]

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