211–220 of 223 posts
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
Default parameters have always struck me as dangerous. (And for my day job I use Python.)
Earlier quoted context omitted.
Go is focused on the distributed systems domain though. It's fine, even desirable, to have languages focused on particular domains, that make design decisions based on the constraints of the domain. In this domain, closed enums are footguns with costly consequences if you get it wrong.
As someone that doesn't work in that domain, could you give a short example?
Earlier quoted context omitted.
What problems did an enum cause you, and how was the enum responsible for the problem?
This is a known issue with Rust, for example. I have an enum with variants A and B. Somebody writes an exhaustive switch (match statement) that handles A and B with no default case. I add a variant C. Their code breaks because they don’t handle C. Adding an enum variant was a breaking change. In Rust, the answer is #[non_exhaustive], which forces consumers to always add a default case. It’s not a huge deal, just a kn…
Earlier quoted context omitted.
> > user code could simulate non-deterministic > I'm curious how? if rand.Intn(2) == 0 { select { case: chan3_whichItreatTheSameAsChan2 } } else { select { case: 0xFF ->chan3_whichItreatTheSameAsChan2 // a higher priority case: Yes, it increases verbosity to the other way, but no performance loss.
How in the world is generating a random number and branching and doubling the number of instructions "no performance loss"?
Doubling the number of instructions has no impact on run-time performance.
And there are more optimization opportunities in implementing a deterministic design. Now, the non-deterministic implementation needs to lock all involved channels before subsequent handling, a deterministic implementation might not need to.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Yes, as I have mentioned, there is performance loss, comparing to select { case: chan3_whichItreatTheSameAsChan2 }
1) Is there really a performance loss compared to if select was deterministic ? 2) What in the world do you need such code for?
2) just read:
https://groups.google.com/g/golang-nuts/c/SXsgdpRK-mE/m/CT7UjJ3aBAAJ
https://groups.google.com/g/golang-nuts/c/ZrVIhHCrR9o
https://groups.google.com/g/golang-nuts/c/lEKehHH7kZY/m/SRmCtXDZAAAJI can write x = &Foo{...} but somehow x = &42 and x = &foo() are not allowed, which forces me in some cases to declare useless variables that hurts readability.
Earlier quoted context omitted.
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
In my experience this isn’t idiomatic Go and would definitely turn heads in a code review. But in such a small function, it’s fine to just not worry about the lifetime of your variables (and in bigger functions you can often decompose into smaller functions).
But "idiomatic" always takes a backseat compared to technical necessity. If there is a requirement, for some reason, to limit the scope of `err` and still allow `result` to be changed in the if's pre-assignment, then this is the way to do it.
Earlier quoted context omitted.
The real usecases where I need deterministic select, are so few that a small performance loss doesn't matter to me.
Sometimes, it is not related to performance loss, it is related to implementation cleanness and complexity.
Two Go 2 proposals that interested me were: * nillability annotations: https://github.com/golang/go/issues/49202 * Change int from a machine word size (int32 or int64) to arbitrary precision (bigint): https://github.com/golang/go/issues/19623 Sadly the nillability annotations were rejected because they weren't backwards compatible. The bigint change is also unlikely to be accepted because the issue is already five ye…
func foo(a, b int) int {
return a * b
}
One of the best things about golang, is how little "magic" there is. Everything that happens is immediately obvious from the code. An int that is upgraded to a completely different type when it reaches certain values, goes directly counter to that; it would be hidden behaviour, not immediately obvious from the code.
Should golang have a builtin arbitrary sized integer type? Maybe. Using math/big can become cumbersome. But a much better solution would be to introduce a new builtin type like `num`