[lpapez]

This was my impression coming to Go as well (from Python and PHP) but since then I've changed my mind and somehow find it easier to unpack a small for loop than a HOF with a lambda function argument.

When you introduce lambdas/closures/HOF you immediately have to think about scope rules, non-local references etc.

Meanwhile, a foor loop is just a for loop.

[xyzzy123]

Until you spawn a goroutine from a loop and suddenly you have to think about scope rules, nonlocal references, etc...

(It doesn't bother me, just noting the same complexities do come up pretty often).

[nasretdinov]

BTW this is actually being addressed, specifically the for loop now essentially captures by value instead of by reference. I believe no real working programs were affected by the change, except for maybe fixing bugs in them.

Proof: https://go.dev/blog/loopvar-preview

[erik_seaberg]

Map and filter name what they’re doing, while loops look too much alike.

I haven’t checked whether any Go compiler does list fusion between producers and consumers (to avoid leaving a slice in the heap after reading it just once).