Philosophy and "for" loops — more from Go and Rust

Thanks. I would categorise both your examples as "other ways to do it which don't improve on the original and are measurably worse", just like the examples I found ;-)

However your comment "information should always flow on a channel from sender to receiver" puzzles me. Surely when I recv from a channel, that causes information to flow back to the sender (for an unbuffered channel at least), as the sender can know that I have read because its "send" has completed.
The information "no one is ever going to read from this channel again" is certainly more information than "someone just read" and if Go developers choose to allow one of those to flow backwards and not the other then that is clearly their choice to make, and maybe it is a good choice.

But I think it is too simplistic to say that information only flows in one direction.