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

101–110 of 223 posts

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

#101

Post by morelisp »

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…

Context cancellation propagates (potentially) asynchronously anyway, so if you're relying on something canceling your context and that immediately appearing you already have a bug.

I've written `select { ..., default: }` enough times I also wish it had shorthand syntax - sometimes it's even clearer to range one "primary" channel and lead the code block with that check - but I cannot think of a case where relying on a deterministic select would not have led to a bug.

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

#102

Post by lolinder »

masklinn wrote: post #70
amw-zero wrote: post #55

Earlier quoted context omitted.

Really not sure what you're talking about. If you use enums in a real language like Swift, Kotlin, Rust, etc., you can only construct the values of the enum. There are no ways to get around it.

> Really not sure what you're talking about. Have you considered reading?

Have you considered elaborating? I am likewise unsure how a language could get enums wrong, even after reading your post.

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

#103

Post by JulianMorrison »

tapirl wrote: post #99
JulianMorrison wrote: post #96

Earlier quoted context omitted.

That wasn't exactly what I meant. What I meant was - as of right now they are different, and clearly distinct, and it's actually important to unlearn thinking of a const as a var, because they don't do the same thing in practical terms - that proposal would muddy the distinction.

Yes, they are different, const values doesn't allocated in memory NOW. But who cares? Most gophers just think const values are immutable values. I mean we could let some const values allocated in memory.

Thankfully the people who make Go do care about conceptual muddles.

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

#104

Post by rplnt »

tapirl wrote: post #78
AtroxDev wrote: post #2

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 t…

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

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

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

#105

Post by morelisp »

coder543 wrote: post #94
masklinn wrote: post #34

Earlier quoted context omitted.

I have to say I’ve no idea what you mean. In function definitions I’d interpret it as type inference (and would disagree) but you specifically talk about function calls , and consider it a small change. Can you describe what you’re thinking of?

I think I understand what they're asking for. Consider a function that takes in a struct as one of the arguments.[0] Currently, you would have to invoke it like so: svc.GetObjectWithContext(ctx, &s3.GetObjectInput{Bucket: bucket, Key: key}) But... why do you have to type "s3.GetObjectInput"? The function is taking in a concrete type (not an interface) for that argument, and there is only one possible type that you ca…

I would also love this. The current rules for when you're allowed to elide are nonsensical.

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

#106

Post by masklinn »

coder543 wrote: post #94
masklinn wrote: post #34

Earlier quoted context omitted.

I have to say I’ve no idea what you mean. In function definitions I’d interpret it as type inference (and would disagree) but you specifically talk about function calls , and consider it a small change. Can you describe what you’re thinking of?

I think I understand what they're asking for. Consider a function that takes in a struct as one of the arguments.[0] Currently, you would have to invoke it like so: svc.GetObjectWithContext(ctx, &s3.GetObjectInput{Bucket: bucket, Key: key}) But... why do you have to type "s3.GetObjectInput"? The function is taking in a concrete type (not an interface) for that argument, and there is only one possible type that you ca…

Ah yes, that does make sense, I would agree. That Rust doesn't have that (in any context that I know of) is one of its annoyances,

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

#107

Post by lanstin »

tapirl wrote: post #98
lanstin wrote: post #87

Earlier quoted context omitted.

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

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.

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.

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

#108

Post by geenat »

mountainriver wrote: post #77

I would really love to see default parameters and struct values. I jump between Python and Go in my day job and Go is a much better language overall but things like this make it painful

This is also my #1.

Parameter / Option ergonomics.

The current best practice of "functional options" and long function chains results in far too many function stubs ... its a minimum of 3 extra lines per parameter. Parameter structs require a whole extra struct...

Borrowing optional / named parameters from Python would cut down length and complexity of Go code drastically.

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

#109

Post by morelisp »

rplnt wrote: post #97
amw-zero wrote: post #52

Earlier quoted context omitted.

This compiles: type Test int const ( T1 Test = 0 T2 = 1 ) func TestSomething(t Test) {} ... TestSomething(17) So this isn't a good suggestion, because you can easily pass any int value and will not get a compiler error. You may as well be using strings at that point.

I mean, that's a pretty common usage of enums, isn't it? TestSomething(T1 & T2)

And this is the big, probably irreconcilable, difference in culture between the sum-typers and the compiler-assisted-named-valuers....

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

#110

Post by bruce343434 »

JulianMorrison wrote: post #72

> Alternatively, Go 2.0 could implement "frozen" global variables A more general change would be to implement the "var" and "val" distinction that exists in some languages. const x = 1 // x is a compile time alias for the untyped abstract number 1 var x := 1 // define x at runtime to be (int)1, x is mutable val x := 1 // define x at runtime to be (int)1, x is immutable Then the globals can be defined with "val".

the val and const cases should hardly be different if the compiler has constant folding, except maybe for the typing.
Post reply on HN