Function Iterators might just change the way we write loops in Go

The rangefunc experimental feature is now available with Go 1.22.

Over the last couple of weeks I have been playing with this new feature to see how far I can push it, and I think it may just change the way we write some loops in Go.

(Website is written in Go, btw)

Video links:

Join this channel to get access to perks:

00:00:00 Intro
00:00:23 rangefunc
00:01:55 Parallel iteration in Go
00:03:46 Convert to Parallel Iterator
00:05:57 Handling Break
00:07:47 Making Generic
00:08:28 Footguns
00:09:08 iter package
00:10:01 Loop package
00:10:38 Conclusion
00:10:59 Good news!

[johnmarianhoffman]

I think a lot of the potential harm that could be caused by this feature would be almost entirely mitigated with a strong standard library implementation of many/most of the most common use cases. I think this approach is fine, and generally needed when writing a lot of iterator-heavy code. This seems fairly reasonable.

What I get scared of is every sophomore programmer thinking they need their own implementation of exotic iterators, writing their own package, and it just creating a bunch more headache that would've been prevented with a simpler or more explicit approach. Not everyone should get equal access to parallel iterators! That comes with some very real risks!😆

[kevinb]

The waitgroup verison of the example is MUCH easier to reason about. I would hate to have to debug that function.

[DerTim]

Nice feature to extend loops, but such an implementation feels difficult to handle and violates the value of simplification. So, whatever the Go Community prefers :)

[coffeeintocode]

This is really powerful. But it feels very un-Go-y……eg it’s too much magic. Obfuscation isn’t good for Go, I know verbosity gives it a bad repo, but I also think this forces better code

[davidgillies]

Python and C++ (modern C++, anyway) make fairly heavy use of generators (in C++ up to 20 they were implemented with input iterators; C++23 has an explicit std::generator class). It's a very powerful pattern for parsing data streams, for example. Node has had something similar since basically forever.

[MarisaClardy]

Nice to see Go finally getting generators. I use this pattern a lot when working in PHP, so good to see it's going to be possible to do it in Go.

[TheQxY]

The syntax is not the most readable, but overall, I'm in favour of the proposal. It will be a very useful tool for the Go devs and for library devs like myself. Endusers don't have to deal with the inner complexity as much and can have a more homegeneous experience dealing with ranges. It's up to the library devs to write self-documenting and readable iterators.

[yakomisar]

Elliott, pls, make a step by step guide on how to use pprof professionally.

[plaintext]

This will be very nice to work with when using remote data sources - just treating them as arrays, imstead of something like 'for val, err := source.Next(); err == nil { dostuff(val) }

[daviddesmarais-michaud]

This video is great. The explanation and animation is great. One nit, the Parallel implementation is wrong. It works because it is unlikely that that race condition will be met once you've canceled the context, but another goroutine could be yielding in as you cancel. This is a classic case where you need a mutex. A potential solution could look like this:

func Parallel[T any](list []T) func(func(int, T) bool) {
return func(yield func(int, T) bool) {
var (
wg sync.WaitGroup
m sync.Mutex
cancel = make(chan struct{})
isCanceled bool
)

wg.Add(len(list))

for i, e := range list {
go func() {
defer wg.Done()

select {
case <-cancel:

default:
}

m.Lock()
defer m.Unlock()

if isCanceled {

}

if !yield(i, e) {

= true
}
}()
}

wg.Wait()
}

[Amejonah]

Every time I'm surprised by the fact that go hasn't all the things I take for granted now in Rust and Kotlin.
I need to make my own stuff too much, it feels like left-pad all over again.

[bijayaprasadkuikel]

Please create a premium course on Go. I am all ready to subscribe to it. 🎉🎉🎉🎉🎉You are probably the best teacher who teaches golang perfectly.

[IgoR.R.]

This experimental feature challenges boilerplate oriented programming.

Jokes aside. It's more convenient for sure. In my opinion it's bad for go's simplicity.

[Redyf]

Go is such a cool language, I just started learning it so this was very helpful. Thanks Dreams!

[niksaysit]

The syntax of "functions returning functions accepting functions that you can pull values from" is too complicated and magic-y. It seems like they're trying to stretch the extra-simplistic syntax of Go1, when it might be better to learn from its shortcomings to come up with Go2

But that's my humble opinion

[qlcorp]

This is an affrontment to my sensibilities.

[Fudmottin]

Parallel processing can definitely get interesting when hidden somewhere down in code you don't know about there is a shared resource. Something like a memory allocator perhaps.

[wonderful-pz]

it seems rust is becoming easier and clear than go. The only good thing i like about go is compile time.

[salamander]

I highly prefer the boiler plate "heavy" way of doing this. No reason to abstract away easy patterns everyone knows

[evrybodygets]

yaaa.... it think go should bench this one. it just seems like the plot has been lost in this feature. i know go wants to be this gc lang that has first class support for concurrency to make up for that but it also promises to stay simple like c. It feels like too big of a sacrifice of the former in favor for the latter....