8 ms·
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
by lpapez 3y ago
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 3y agoUntil 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 3y agoBTW 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 https://go.dev/blog/loopvar-preview
- erik_seaberg 3y agoMap 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).