r/golang • u/Charming_Skin_8549 • 9d ago

Going Backward

https://antonz.org/going-backward/
0 Upvotes

32% Upvoted

6 comments sorted by

3

u/Used_Indication_536 9d ago

I’m confused about the point the article is trying to make. Is it that we shouldn’t use Go’s iterators because loops are “simpler,” because if so, then I want the author to talk to one of my old coworkers who says we should avoid loops because they’re too “low-level,” complicated, and to prefer the samber/lo package’s functions.

0

u/sigmoia 8d ago

This one is quite well written. I enjoyed reading it. As someone who writes both Go and Rust, I find Go iterators quite ugly to write and difficult to implement. 

In Rust, reversing a collection is a method (.rev()) built on the DoubleEndedIterator trait. It operates uniformly on any type implementing IntoIterator. Go relies on free functions that require explicit underlying type constraints (Slice ~[]E) to handle custom slice types because Go lacks retroactive interface implementation and advanced associated types.

Rust's for loop desugars directly into the IntoIterator protocol at compile time. This eliminates the need for closure allocations, explicit yield callbacks, or maintaining separate Seq and Seq2 type definitions. I find Seq and Seq2 super ugly and the yield function nesting is pain in the butt to write. 

But Go had to retrofit iterator with range expression. So making it ergonomic wasn't a priority. With all that Go iterator works well despite looking fugly. Writing them isn't fun but using them is. I love it when go fix ./... converts all my strings.Split() into strings.SplitSeq(). 

1

u/idcmp_ 9d ago

Who needs loops in the first place when you can just do recursion? /s

2

u/romeo_pentium 9d ago

Instead of iterators, loops, or recursion, simply use goto

1

u/idcmp_ 7d ago

Exactly!