5 ms·

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 rel

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_to_see_in_go_20/hsvv99z/ https://old.reddit.com/r/golang/comments/s58ico/what_id_like...

dewey 5y ago
> 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 5y ago
  It'd be nice if he had at least hinted towards what 'the way' is for this problem.
  - cle 5y ago
    It’s in the article he’s responding to.
tapirl 5y ago
> 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).
- lanstin 5y ago
  Any time there is more than one channel being selected for it needs to cover them all equally.
  - tapirl 5y ago
    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 5y ago
      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.
    - lanstin 5y ago
      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 5y ago

dewey 5y ago

> 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 5y ago
It'd be nice if he had at least hinted towards what 'the way' is for this problem.
- cle 5y ago
  It’s in the article he’s responding to.

tapirl 5y ago

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

lanstin 5y ago
Any time there is more than one channel being selected for it needs to cover them all equally.
- tapirl 5y ago
  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 5y ago
    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.
  - lanstin 5y ago
    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 5y ago