I was just trying to see the what the highest rated stack overflow questions of all time. Turns out, “What does the yield keyword do in Python?” is number 5. I have always like yield in Python, but I think that’s a bit damning.
That would go against the Go philosophy. And frankly it’s not that much more complicated, just incredibly verbose and burdensome but that’s in keeping with the usual philosophy of Go. The translation is quite mechanical, something like:
if the generator takes parameters return a func(func(yieldType) bool) and wrap the generator body in a func(func(yieldType) bool) {}
If Go someday maybe gets some kind of error-related early return, it could look like try yield(v) or yield(v)! or whatever and that would be pretty good.
The other thing this really makes you want is a shorter syntax for declaring functions. But I guess in practice you don’t make as many new iterators as ones you use, so maybe it’s fine.
I don’t see the argument for this in Go, to be honest. func() vs () => saves you what, two characters? It’s the type annotations that take up all the space, and that wouldn’t change.
7 when you include the return statement, as the most flagrant use cases for it are single-expression functional callbacks, and the linked comment includes obviating that much like arrow functions do in Javascript, or lambda in Python (even though it wastes much of the gain on the lambda keyword itself).
and that wouldn’t change.
It could though, similar to Rust which mandates annotations on named functions but allows leaving them out on anonymous functions. The contexts which would benefit from arrow functions generally constraint the types significantly, and since they would be internal to function bodies it would not be dissimilar to Go’s existing limited type inference on locals variable.
I see, so this is really more analogous to rust lambdas, then? In which case this is a lot more than just different syntax. I can see the appeal of that.
https://antonz.org/go-1-22/
rand.N working for time durations will be really handy.
Really saving me from myself with the for loop footgun fix
Psst, they’re not saving you from yourself — they’re saving you from the footgun.
I’m happy with all the library improvements. And changing how
forworks to avoid dumb problems is great as well.But:
maybe say that’s going too far, for a language which keeps things simple?
I would love to see something as simple to use as
yieldin python tbhyieldis super confusing!How so? It is the easiest iterator pattern I have ever seen. The runtime implementation may be complicated, but the syntax/UX is great.
I was just trying to see the what the highest rated stack overflow questions of all time. Turns out, “What does the yield keyword do in Python?” is number 5. I have always like yield in Python, but I think that’s a bit damning.
https://stackoverflow.com/questions?sort=votes
Top question is basically about branch prediction and 2-4 are all git questions, which also says a lot about git.
That would go against the Go philosophy. And frankly it’s not that much more complicated, just incredibly verbose and burdensome but that’s in keeping with the usual philosophy of Go. The translation is quite mechanical, something like:
if the generator takes parameters return a
func(func(yieldType) bool)and wrap the generator body in afunc(func(yieldType) bool) {}replace every
yield valuebySo, in practice, usage now looks like
If Go someday maybe gets some kind of error-related early return, it could look like
try yield(v)oryield(v)!or whatever and that would be pretty good.The other thing this really makes you want is a shorter syntax for declaring functions. But I guess in practice you don’t make as many new iterators as ones you use, so maybe it’s fine.
Honestly, I would love javascript style arrow function expressions in Go for exactly this.
See https://github.com/golang/go/issues/21498#issuecomment-1132271548
I don’t see the argument for this in Go, to be honest.
func()vs() =>saves you what, two characters? It’s the type annotations that take up all the space, and that wouldn’t change.7 when you include the
returnstatement, as the most flagrant use cases for it are single-expression functional callbacks, and the linked comment includes obviating that much like arrow functions do in Javascript, orlambdain Python (even though it wastes much of the gain on thelambdakeyword itself).It could though, similar to Rust which mandates annotations on named functions but allows leaving them out on anonymous functions. The contexts which would benefit from arrow functions generally constraint the types significantly, and since they would be internal to function bodies it would not be dissimilar to Go’s existing limited type inference on locals variable.
I see, so this is really more analogous to rust lambdas, then? In which case this is a lot more than just different syntax. I can see the appeal of that.
I have to agree. This is the first change to Go that I really don’t like.