This is the textbook definition of the Blub Paradox[1]. If you've mostly used Go (or moved to Go from JavaScript before it had iterators, or from Java where ite

This is the textbook definition of the Blub Paradox[1]. If you've mostly used Go (or moved to Go from JavaScript before it had iterators, or from Java where iterators are a royal PITA to write), it won't make sense. That's okay, since it is often hard to imagine how a feature will be used without getting used to it yourself. I'm pretty sure that most FORTRAN 66 developers coming to Go would be puzzled on why you need for loops at all, when you can write DO loops and specify the line number where the loops end (older Real Programmers[2] don't even understand why you need loops at all, since you can always GOTO anywhere you'd like). So to cut it short, iterators, as Go implements them, should be useful at least for the following cases: - Iterating over custom collections (e.g. trees, concurrent maps, queues) that are not provided by the language (and "range for" doesn't have custom code for inside the compiler). - Iterating over a collection in a different way, for instance filtering out some elements or iterating over the collection backwards (as in the giving example). - Reification - if abstract iterators can be passed to functions (instead of actual slices), you can write functions that operate on a theoretically infinite stream. - Chaining iterators. If iterators can be reified, you can also chain them together. This is somewhat cumbersome with the syntax Go 1.23 will offer, but in many languages you can write code like this: let incompatibleTransactions = user.Accounts .Filter(account -> account.Balance <= 0) .FlatMap(account -> account.PendingTransactions()) .Filter(tx -> !tx.AllowCredit()) Once you know what each function does, it is clear that the code goes through all the accounts that have a zero or negative balance and returns all the pending transactions that do not allow credit from these accounts. The equivalent imperative code is harder to figure out at first glance incompatibleTransactions := []Transaction{} for _, account := range user.Accounts { if account.Balance < 0 { for tx := range account.Transactions { if !tx.AllowCredit() { incompatibleTransactions = append(incompatibleTransactions, tx) } } } } If the accounts and transactions collections are not built-in the iteration code would even look worse. This code is harder to read since it conflates the What (what we want to achieve with the code) with the How (how to implement this with a for loop). Obviously, this is what imperative programming is all about, and Go is indeed becoming less imperative. [1] http://wiki.c2.com/?BlubParadox http://wiki.c2.com/?BlubParadox [2] https://sac.edu/AcademicProgs/Business/ComputerScience/Pages/Hester_James/Real%20Programmer.htm https://sac.edu/AcademicProgs/Business/ComputerScience/Pages...