Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I'd like to see in Go 2.0

sethvargo.com

Post reply on HN
Print view View original

131–140 of 223 posts

Re: What I'd like to see in Go 2.0

#131

Post by usrbinbash »

t43562 wrote: post #20

Everyone has their own gripes. Modules are what cause me the most pain in Go - especially where they're in github and I need to fork them and now change all the code that references them. I don't know if the problems are even tractable because the way it all works is so incredibly complicated and any change would break a lot. I would like to remove all the "magic" that's built-in for specific SCMS/repository hosting…

Easily fixed using lexical scopes:

    func doThing() string {
        result := "OK"

        {
            var err error
            if result, err = somethingElse(); err != nil {
                return "ERROR"
            }
        }

        return result
    }
`err` is introduced in the lexical scope, `result` isn't so it still refers to the string from the surrounding scope. `err` does not pollute the surrounding scope.

You can also try the complete version here: https://go.dev/play/p/kDEB11YdvSs

Re: What I'd like to see in Go 2.0

#132

Post by mikepurvis »

JulianMorrison wrote: post #88
tapirl wrote: post #84

Earlier quoted context omitted.

No need to invent a new keyword, it is ok to just use "const": https://github.com/go101/go101/wiki/An-immutable-value-propo...

No, they are very different conceptually. - A const is an abstracted value. - A variable is an allocated piece of memory.

Isn't that an implementation choice?

Like in C++, a const is absolutely allocated since you can get a pointer to one. And then you can do horrible stuff like const_cast that pointer and mutate the value, and the possibility of that occurring prevents the compiler from doing certain const-related optimizations.

Re: What I'd like to see in Go 2.0

#133

Post by tapirl »

lanstin wrote: post #114
tapirl wrote: post #98

Earlier quoted context omitted.

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.

Re: What I'd like to see in Go 2.0

#134

Post by usrbinbash »

jaggederest wrote: post #83
rocqua wrote: post #51

Earlier quoted context omitted.

Part of the reason OP liked the `if assignment` was to avoid polluting the higher-level scope with a variable that is only needed during the if statement. Your solution fixes the error, but at the cost of losing the upside OP saw.

Is there no equivalent to a lexical scope let definition? let { var err := error scoped code }

Of course there is:

    {
        var err error
        scoped code
    }

Re: What I'd like to see in Go 2.0

#135

Post by ptomato »

jaggederest wrote: post #83
rocqua wrote: post #51

Earlier quoted context omitted.

Part of the reason OP liked the `if assignment` was to avoid polluting the higher-level scope with a variable that is only needed during the if statement. Your solution fixes the error, but at the cost of losing the upside OP saw.

Is there no equivalent to a lexical scope let definition? let { var err := error scoped code }

yes, you can wrap code in {} to scope it.

Re: What I'd like to see in Go 2.0

#136

Post by sethvargo »

assbuttbuttass wrote: post #41
sethvargo wrote: post #39

Earlier quoted context omitted.

It really doesn't though. It handles the case where the context might have expired or be cancelled, but there's still a race when entering the select between the ctx.Done() and reading from thingCh. You may end up processing one additional unit of work. In situations where the exit condition is channel-based, this won't work. Additionally, this would only work if you had one predominant condition and that condition w…

I'm not sure what you mean. There's always going to be a race condition between ctx.Done and thingCh, just depending on whether there's data available. This race condition is unavoidable. I guess you're thinking of "what if thingCh and ctx.Done activate simultaneously?" There's no real difference between happening simultaneously and happening one after another. As for your other point, you can just write code like se…

Also, this isn't semantically correct. In order to ensure that `conditionaA` is _always_ preferred over `conditionB`, you must also check if `conditionA` has received a value inside of `conditionB`:

    select {
    case a :=

Re: What I'd like to see in Go 2.0

#137

Post by sethvargo »

oconnor663 wrote: post #62
sethvargo wrote: post #47

Earlier quoted context omitted.

Right, which is noted in the post. That verbosity is, well, verbose. I generally need this in 20% of things I write.

In this use case, is it bad if the Done signal arrives the instant after you check it?

The context was introduced by the commenter. The original post does not use contexts. In general, there's a pretty common set of patterns in which multiple goroutines are writing data to different channels, and you need to ensure the data from those channels are processed with some level of priority.

Re: What I'd like to see in Go 2.0

#138

Post by mkdirp »

rplnt wrote: post #100
mkdirp wrote: post #95

Earlier quoted context omitted.

I generally tend to use enumer[0] to generate some boilerplate code that can help with addressing this, e.g. the below would compile, but would error at runtime. There are probably linters out there that could catch this. With Go, linters are generally pretty good at catching this kind of stuff. package main import "fmt" type Test int const ( T1 Test = 0 T2 = 1 ) func main() { t, err := TestString("T1") if err != nil…

> as opposed to actually having it Like C or C++ do? :)

Right. However, C and C++ are far more complex, with no memory safety. Everything has it's ups and downs.

Re: What I'd like to see in Go 2.0

#139

Post by usrbinbash »

tapirl wrote: post #123
usrbinbash wrote: post #120

Earlier quoted context omitted.

> Not vice versa (the current design). select { case: chan3_whichItreatTheSameAsChan2 }

Yes, as I have mentioned, there is performance loss, comparing to select { case: chan3_whichItreatTheSameAsChan2 }

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

Re: What I'd like to see in Go 2.0

#140

Post by assbuttbuttass »

sethvargo wrote: post #136
assbuttbuttass wrote: post #41

Earlier quoted context omitted.

I'm not sure what you mean. There's always going to be a race condition between ctx.Done and thingCh, just depending on whether there's data available. This race condition is unavoidable. I guess you're thinking of "what if thingCh and ctx.Done activate simultaneously?" There's no real difference between happening simultaneously and happening one after another. As for your other point, you can just write code like se…

Also, this isn't semantically correct. In order to ensure that `conditionaA` is _always_ preferred over `conditionB`, you must also check if `conditionA` has received a value inside of `conditionB`: select { case a :=

It would be easier to discuss with a more concrete example. If I ever had to write code like the above I would reconsider the design and try to come up with something simpler.
Post reply on HN