Are those unwise things? Things in go could panic, even if you do only “wise” things. Specifying how things will behave in those situations down to what the stack trace will show is a good idea and likely took a lot of work compared to the happy path.
Generics was already too much.
I limit their usage to shared library code. Otherwise, everything becomes coupled.
This new proposal exponentially increases the number of ways to write the same functionality, which makes it similar to existing feature-rich languages. This is bad.
How can it “exponentially increase” the number of ways to write a functionality when there was already an infinite number of ways to write it, and the standard library alone has half a dozen different ad-hoc implementations of iteration?
As German mathematician Georg Cantor demonstrated in the late 19th century, there exists a variety of infinities—and some are simply larger than others.
Currently there’s an infinity of ad-hoc iteration patterns used nilly willy with no consistency. What this proposal does is essentially take one of those patterns and “bless” it, by supporting it with range.
Pretty much. The hope is that in practice the amount of variation will reduce. Of course, it’s just a hypothesis for now, but in practice iterators are widely used in every language that has them, so it seems a pretty safe bet.
For posterity: there’s only at most a countably infinite number of programs in any given language, as long as the underlying alphabet is finite. All countable infinities have the same cardinality; they’re in bijection with the natural numbers.
This post (and the related discussion here and elsewhere) reminded me of something Roberto Ierusalimschy wrote. (He’s talking about writing iterators for the generic for in Lua.)
This is a common situation with iterators: they may not be easy to write, but are easy to use. This is not a big problem; more often than not, end users programming in Lua do not define iterators, but just use those provided by the application (Programming in Lua, 2nd ed., 56).
So, yes, the code to create these functions is more complex to write and read than average Go code, but that may be fine. Most people will use such iterators (which they get from the standard library or modules) more often than they write or read them, and (as Ierusalimschy says) “they easy to use.”
Amusing how half the FAQ is what happens if I do something obviously unwise?
Are those unwise things? Things in go could panic, even if you do only “wise” things. Specifying how things will behave in those situations down to what the stack trace will show is a good idea and likely took a lot of work compared to the happy path.
I am super excited for this!
Same! Hopefully, the first step in unifying lots of disparate iteration APIs.
This is making go less appealing to me.
Generics was already too much. I limit their usage to shared library code. Otherwise, everything becomes coupled.
This new proposal exponentially increases the number of ways to write the same functionality, which makes it similar to existing feature-rich languages. This is bad.
How can it “exponentially increase” the number of ways to write a functionality when there was already an infinite number of ways to write it, and the standard library alone has half a dozen different ad-hoc implementations of iteration?
And this is not the case here.
Yeah no you’re utterly off base.
Currently there’s an infinity of ad-hoc iteration patterns used nilly willy with no consistency. What this proposal does is essentially take one of those patterns and “bless” it, by supporting it with
range.Pretty much. The hope is that in practice the amount of variation will reduce. Of course, it’s just a hypothesis for now, but in practice iterators are widely used in every language that has them, so it seems a pretty safe bet.
For posterity: there’s only at most a countably infinite number of programs in any given language, as long as the underlying alphabet is finite. All countable infinities have the same cardinality; they’re in bijection with the natural numbers.
This is going to be really great. Better iterators would be so useful.
This post (and the related discussion here and elsewhere) reminded me of something Roberto Ierusalimschy wrote. (He’s talking about writing iterators for the generic
forin Lua.)So, yes, the code to create these functions is more complex to write and read than average Go code, but that may be fine. Most people will use such iterators (which they get from the standard library or modules) more often than they write or read them, and (as Ierusalimschy says) “they easy to use.”
Yessss, slowly reinvent Python 🐍
See my blog post from 2014! https://blog.carlana.net/post/on-using-go-channels-like-python-generators/