Get the latest tech news

The upcoming iterator design for Go 1.23

NOTE: This is based on, but completely rewritten, from a Twitter post: https://x.com/TheGingerBill/status/1802645945642799423 TL;DR It makes Go feel too “functional” rather than being an unabashed imperative language. I recently saw a post on Twitter showing the upcoming Go iterator design for Go 1.23 (August 2024). From what I can gather, many people seem to dislike the design. I wanted to give my thoughts on it as a language designer. The merged PR for the proposal can be found here: https://github.

Make the iterator look/act like a generator from other languages (thus the yield) Minimize the need for sharing too many stack frames Allow for clean-up with defer Reduce data being stored outside of the control flow The approach that Go 1.23 takes seems to go in the face of the apparent philosophy of making Go for the general (frankly mediocre) programmer at Google who doesn’t want to (nor can) use a “complex” language like C++. When I am working on those kinds of problems, they will always be either a contiguous array, or I will implement the algorithm manually because I want to guarantee the performance will be good for that data-structure.

Get the Android app