[ewencp]

You need them because the examples are intentionally simplified. Even a data structure as simple as a dictionary has a useful variety of iterators: over keys, over values, and in some languages, over (key,value) tuples. Explicit iterators are really only noise for the "natural" iterator, i.e. in order iteration over an array.

I agree that having it hidden by a language feature is nice, but somewhere there is an iterator -- the class that supports that iteration must at least specify how it's accomplished. I would prefer if there were an easy way to integrate with the range keyword in Go.

EDIT: Adding to reply to some added comments. The close() one in particular really threw me. It makes sense in terms of how channels work, but is really unfortunate. When I first saw the channel-based approach, I thought it was a neat solution. But then I found all the problems with it (including the best example I could find of it online missing that close(), which is why I pointed it out!).

I think Go is close to getting it right if they would do what I mention at the end of the article: provide a way to hook into the range keyword.

[laureny]

> Explicit iterators are really only noise for the "natural" iterator, i.e. in order iteration over an array.

Not really, they are really noise in a lot of situations. Right now, I can only think of one case where they are necessary: lazy traversal. Either the collection is huge or each element is expensive to materialize, so you want to do that one at a time. Iterators are perfect for this.

They are unnecessary in all other cases. For example, for your (key, value) example:

    for (Entry<String, String> entry: map.entrySet()) { ... }

Go exposes too many implementation details to my taste.

[ewencp]

Fair enough. My day-to-day coding with Go right now involves large data sets where materializing something like that would be expensive. I'll admit my view of the issue is strongly biased by my very real need for iterators or something equivalent that can avoid that cost!

[aaronblohowiak]

in the callback approach, you can pass in the current item and a Breaker or maybe a RewindBreaker that you can easily _ when you don't care about it.

[microtonal]

They are unnecessary in all other cases. For example, for your (key, value) example:

But the Java 'foreach' loop is just syntactic sugar around iterators, and your fragment will expand to:

  for (Iterator<Entry<String, String>> iter = map.entrySet().iterator(); iter.hasNext(); ) {
    Entry<String, String> entry = iter.next();
  ...
  }

For this reason, the foreach-loop requires that the object that you loop over implements the Iterable interface.

[RyanZAG]

I believe that's what the parent is talking about. There isn't any reason for Go not to have similar syntactic sugar for something as common as looping through an iterator.

To be honest, every release of Go feels more and more like Java anyway. I won't be surprised when Go eventually ends up being a JVM-less Java in the same way a new OS will end up being unix. After all, "Those who don't understand Unix are condemned to reinvent it, poorly." – Henry Spencer

Maybe Java is the same way? Not to say unix (plan 9?) or java (scala?) are perfect, but there is a reason they are popular.

[microtonal]

Indeed. Disdain toward Java is strange, given Go's popularity and its similarity to earlier Java versions.

Sure, the JVM has long startup time (why should we care for most applications?) and gc/gcc-go produces nice binaries. But the Java ecosystem has many attractions as well: a common runtime for different programming languages, a wealth of high-quality libraries, a mature GC, great package management (via Maven or sbt), good IDEs, hotswap, instrumentation, etc.

Most of Go's advantages (lightweight threads, channels, good compile times) are also available in Java and the JVM.

IMHO it would've been more interesting if Google had pushed Java AOT compilation forward instead. But I guess the point of 20% time is that people can do what the heck they want. Perhaps RoboVM will push the envelope instead ;).

I wonder if they disapproval of the JVM is mostly shaped by slow and ugly AWT/Swing applications and huge frameworks that require lots of XML configuration. (Swing an be pretty, see IntelliJ. I try to avoid frameworks ;).)

[threeseed]

Have to agree that the JVM's long startup time is pretty overblown. It is a fraction of the total startup time of a typical app and there are quite a few caching solutions e.g Drip already.

And IMHO one technology is responsible for much of the hatred towards Java and that is Spring.

[RyanZAG]

I think Google's disapproval of the JVM is shaped by Oracle's lawsuits and is purely political, as they were extremely in favour of the JVM before those occurred.

[anon1385]

That's probably true, but some of the Go creators (Pike for example) have been saying very negative things abut Java since long before the Oracle lawsuits. Often in fairly trollish ways.