[duped]

This isn't "lots of science" it's rudimentary software engineering...

Sending data through channels just to implement an iterator seems insane. It's not strictly lazy either...

Why do go developers reject simple patterns that make faster code?

[rad_gruchalski]

How are those magical lazy operations implemented in other languages? Someone had to take that insane step. It’s just not by default in go.

Look, I’ve written lots of scala and erlang so I get your argument. It just does not exist in go. And that’s okay.

Never got caught thinking “gee, need a lazy collection”. Maybe a stream when reading stuff from the ether. In go, channel was enough. 5 minute job. Nothing insane.

[duped]

They're implemented with closures, not passing things through FIFOs. It's not magic. You barely need a compiler pass to implement the sugar for `for` loops: it's a trivial transformation to a `while`.

[rad_gruchalski]

Okay, but what’s the benefit for go. I can iterate over slices, maps and channels (for ... range). Slices must have a capacity defined. What’s the benefit of lazy iterator?

for over a channel is in essence lazy. Channel stores the data as a linked list. So what’s the benefit.

[duped]

The benefit of generic iterators or implementing iterators lazily? The benefit of generic iterators is that they make SOLID programs easy to write, especially when converting data. It makes any kind of data ingest or hand rolled parsing/semantic analysis easy to write, read, and hard to screw up - which is 90% of business logic.

Lazy evaluation is the only reasonable way to implement iterators so you don't have to pay the costs of intermediate data structures or sending data over channels. Insertion into a data structure isn't free. Function composition is.