This is why I'm despairing so much over Go's popularity after using C#/F# and Rust which have rich and idiomatic iterator APIs. Go implementation is plain ugly, flawed and, most of all, is going to be slow unless you write it in the most verbose way due to Go's compiler weakness.
There are languages that move us forward, Go sets us back by 20 years.
Take these things a little less personally. Live and let live. People think differently from you, and that's okay.
Instead, people shoehorn it into data processing and databases, the domain at which .NET is incomparably more adept due to performance primitives it offers, if we still talk high-level-ish languages with automatic memory management. Of course if there is no such requirement, there are many (like Zig, Rust and C++) systems programming languages that are better in every possible way at solving the task. And yet, we get Go and startups struggling to scale. But all the interesting problems in which Go is attempted to be applied to, where the solution, if successful, is despite Go not because of it, would have benefited from C#/F# which offer much better control and performance assurances, without having to fight the tool.
I have meticulously benchmarked Go in previous roles and also used Go as a load generator and with smart allocation strategies the language is quite fast. I think you're letting your emotions cloud your judgement but that's nothing new in PL discourse. There's no better way to bring out those that identify with/against programming languages than PL discourse.
See, I would not call Zig unexpressive. I've written a number of iteration structs in Zig, because it has true optionals this is easy, using them is just:
var iter = thing.iterateSomeWay();
while (iter.next()) |item| {
// do stuff
}
Also by not doing enough to make UNIX culture startups have a different opinion of Microsoft, instead of still doing M$ jokes.
The same kind of startups that won't have any qualms adopting Swift, or dealing with its current poor state on GNU/Linux.
By way of analogy, consider that almost any language is missing lots of features present in some other languages. For example, Go does not have inheritance. If I do not miss that feature while using it, that does not necessarily mean that I'm a Blub victim.
As for the chaining, yes I do miss filter and map but is again totally doable with vanilla slices (they just haven’t added those methods to the slices package).
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:
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
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 [2] https://sac.edu/AcademicProgs/Business/ComputerScience/Pages...