this post was submitted on 10 Feb 2024
1 points (54.5% liked)

Golang

2201 readers
5 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

founded 1 year ago
MODERATORS
Ategon@programming.dev
austin@programming.dev
RandomDevOpsDude@programming.dev
1
Questioning Go's range-over-func Proposal (rulmer.xyz)
submitted 9 months ago by codesoap@feddit.de to c/golang@programming.dev
6 comments fedilink hide all child comments
 

I've seen that a new "range-over-func" experiment is available with Go 1.22. In this article, I took a closer look and evaluated the feature for myself.

top 6 comments
sorted by: hot top controversial new old
[–] nemith@programming.dev 3 points 9 months ago (1 children)

Article is missing a lot of keys points. With iterator you can chain them together to provide even higher level abstractions.

There are plenty of containers (new maps with different algorithms like a BtreeMap, linked lists, etc) that now with generics could also use a generic way of iterating over them.

There was a pre-proposal discussion that went into a lot of detail of what is possible that wasn’t intended the release notes. I highly suggest the writer of this article dig much deeper into more benefits of iterators than the two trivial options that were included in the experiment description.

[–] codesoap@feddit.de -2 points 9 months ago (2 children)

Thanks for sharing your opinion with me!

What I'm hearing is basically "you don't understand the real benefits, so your not qualified to judge the proposal". I find this attitude quite harmful. If you think, I'm missing something important, please tell me about it. You will only convince me with arguments, not by patronizing me. Could you at least link the mentioned discussion?

There are plenty of containers [...] could also use a generic way of iterating over them.

To me, it seemed intended, that Go only has two first-level containers (slices and maps). It forces a certain amount of "uniformity" by giving other containers a disadvantage. Of course, in some scenarios you really need a different container and it will be more cumbersome to use, but it is by no means impossible without range-over-func.

[–] icb4dc0de@programming.dev 3 points 9 months ago (1 children)

I think this https://github.com/golang/go/discussions/56413 is the discussion.

Also an interesting read from Russ Cox: https://research.swtch.com/coro

I’d like to add that in my perception you’re a little bit overreacting. I can’t say that I got the same impression that you apparently got from the first comment. To me it sounds as if it’s primarily about missing some depth and could use some more advanced examples - especially when compared to the post Russ Cox wrote 😅 no offense!

[–] codesoap@feddit.de -1 points 9 months ago (1 children)

Maybe I'm a little tired. I've argued a lot about this on reddit as well and have become a bit frustrated with people telling me I'm missing things, without being able to actually provide any convincing real world examples. It's not my goal to cause drama or offend anyone. Sorry, if I came across a little cranky.

Thanks for linking some resources! I'll take a look and see if I can find some compelling arguments there.

[–] icb4dc0de@programming.dev 2 points 9 months ago* (last edited 9 months ago)

I can imagine how…exhausting these discussions were 😅

Apart from the more synthetic examples and the obvious things like iterating custom containers - I understand your argument that this is not a every day use case but there are certainly some use cases - there are things like:

  • iterating a bufio.Scanner
  • iterating SQL results
  • streaming chunked HTTP results

That can benefit from the range-over-func approach.

Furthermore there’s another “class” of tasks that are quite a good fit: generators 😍 Think of an infinite slice of random numbers or Fibonacci numbers or prime numbers…all of this can be expressed as a function you can iterate and “just stop” as soon as you have enough.

Probably this gives you an idea what else the whole experiment is good for 😉

Edit: there’s for instance a Python library letting you generate the holidays of a state for the next 1000 years based on some algorithm without having the data pre-calculated/stored anywhere but you can iterate/filter/… whatever you want

[–] nemith@programming.dev 3 points 9 months ago

No harm intended but if you are reaching a conclusion that such a feature is not needed without going into more detail than “harm” can go the other way as well.

Sorry I didn’t link the discussion as I was on my phone and no partonization was intended.