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

41–50 of 223 posts

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

#41

Post by assbuttbuttass »

sethvargo wrote: post #39
assbuttbuttass wrote: post #35

Earlier quoted context omitted.

I would write the author's example as follows: for ctx.Err() == nil { select { case The extra check for ctx.Err before the select statement easily resolves the author's issue.

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

    select {
    case x :=
But I've personally never needed code like this.

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

#42

Post by szastamasta »

masklinn wrote: post #25
szastamasta wrote: post #21

Earlier quoted context omitted.

Nope, this is exactly what has killed Python3. There is only one way forward - old code still has to work or people will simply stay on 1.0 forever.

I mean… yes, but also, not even remotely. Languages like Rust have solved this through the concept of editions (or whatever you want to call it), essentially package or module-level “compilation mode” which allows evolving the language without breaking the old code. The issue of the Python transition is that it was way too massive and the repercussion were way too widespread (e.g. they necessarily leaked into the API…

If you can make compiler work with both - new and old code, then yes, I totally agree. But Python expected you to transpile your code to new version and recompile while also updating many of your dependencies. And that’s not something you easily can do in large codebases.

I’m not sure how editions in rust work, but if compiler can compile all editions and link them in single binary, then its something I’m totally for. But if someone expects people to go through millions of lines of old code and make sure it all works fine after migration to new version of lang, then I’m not sure your language can succeed.

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

#43

Post by mseepgood »

cle wrote: post #19
mieubrisse wrote: post #4

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update…

Personally I’ve run into more problems with strict enum types in distributed systems in a team setting, than I have with Go’s lack of them. In that setting, strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values. When there’s no clear winner in terms of tradeoffs, I prefer to leave it out of the language like Go has done.

> strict enums are usually over-strict and eventually you back yourself into a corner in terms of being able to roll out new enum values.

Yes, they are poison for the evolution of a public API.

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

#44

Post by tialaramex »

mseepgood wrote: post #6
mieubrisse wrote: post #4

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update…

I don't think you would need a 2.0 (backward-incompatible language change) for any of this.

Exhaustive switch seems likely to be backward incompatible if done well.

What you want here is something akin to Rust's match behaviour on enumerated types. If your alternatives aren't exhaustive, it doesn't compile. Now, Rust is doing that because match is an expression. Your day matching expression needs a value if this is a Thursday, so not handling Thursday in your day matching expression is nonsense - even though often the value of a match isn't used and might be the empty tuple it necessarily must *have a value.

It seems to me that today a Go Switch statement operating on days of the week can omit Thursday and compile just fine. Exhaustive switch means that's a compile error. If your "exhaustive switch" is optional or just emits a warning, it won't catch many of the problems for which exhaustive switch is the appropriate antidote.

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

#46

Post by vasergen »

Not go developer, just curious about the language and ecosystem and really like it. For me would be nice to have more functional features. For example - explicitly say that a variable is mutable / immutable, preferably have immutability by default. Also native support for map/filter/reduce/etc. Those are good abstraction and it is easier to read than `for loops`, since you don't need to look over shoulders all the time. Guess latest would be easier to add since there is support for generics already.

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

#47

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…

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

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

#48

Post by donatj »

mieubrisse wrote: post #4

I'd add one more to this list: proper enum types. We use enums heavily to force devs who use our code into good choices, but the options are currently: 1) Use int-type enums with iota: no human-readable error values, no compile-time guard against illegal enum values, no exhaustive `switch`, and no autogenerated ValidEnumValues for validation at runtime (we instead need to create ValidEnumValues and remember to update…

> Use int-type enums with iota: […] no compile-time guard against illegal enum values

Create a new int type and use that for your enums. While you still can create an illegal enum value, you basically have to be looking for trouble. It’s not going to happen accidentally. It’s even harder if it’s an unpunished type in a different package.

See:

https://github.com/donatj/sqlread/blob/91b4f07370d12d697d18a...

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

#49

Post by jerf »

vasergen wrote: post #46

Not go developer, just curious about the language and ecosystem and really like it. For me would be nice to have more functional features. For example - explicitly say that a variable is mutable / immutable, preferably have immutability by default. Also native support for map/filter/reduce/etc. Those are good abstraction and it is easier to read than `for loops`, since you don't need to look over shoulders all the ti…

"Also native support for map/filter/reduce/etc."

Native support for them in the context of the existing Go spec will be coming with the next release. To reserve the right to evolve the native support before committing it to the backwards compatibility promise, it will initially appear in the https://pkg.go.dev/golang.org/x/exp external repository, but that is the official Go repo for things either too unstable to be included in the standard library, or still experimental. General expectation is it'll be in the standard library in the release after that. It won't be in the standard library, but it's as official as it can be beyond that.

I carefully phrased that with "in the context of the existing Go spec", because I think expectations of this support are wildly out of whack with the reality. It's still going to be a very unpleasant style to work in, with many and manifold problems: http://www.jerf.org/iri/post/2955 . I think people will be crazy to turn to that style in Go. Go wasn't just missing generics to support this style, it was missing many things, and "solving" the generics problem still leaves it missing many things.

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

#50

Post by mseepgood »

bstpierre wrote: post #7

Serious question: what are the odds that go 2 ends up like python 3 and it takes the world over a decade of pain to migrate? (I like both python and go, and I’m still maintaining a sizable body of py2 code.) “Backwards compatibility forever” seems like unnecessary shackles, and the language should be able to grow — I’ve seen some nice proposals for improvements. I just wonder what the strategy is going to be for migr…

> Serious question: what are the odds that go 2

The Go maintainers already said that they don't have any plans to do an actual version 2.0 anymore. Generics turned out to be possible without breaking backward-compatibility.

Post reply on HN