[dcposch]

The zero-copy IO in Go is so elegant.

I think you can really judge a language accurately by checking out its standard library. This is one of my favorite things about Go.

By comparison,

* The C++ STL. Fast and useful, but the implementation is nearly unreadable due to template soup. Here's one of the simpler parts! https://www.sgi.com/tech/stl/stl_vector.h

* PHP. So bad it's basically a strawman. I'll include it because it's hilarious: http://www.forbes.com/sites/quora/2012/08/31/what-are-the-mo...

* Java. A bit better. Compare the readability of OpenJDK's ArrayList.java to the STL vector.h, which does essentially the same thing: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/00cd9dc3c2b5/s...

But of course the Java standard library is immense and has a lot of cruft in it. To write clean Java you really need to avoid much of the standard library (read Effective Java by Josh Bloch) and add a few important missing parts (use Guava).

Golang is really unique in that regard. You can learn Go by reading the standard library. It is beautiful, linear code. The library is pretty complete--eg you can write a one-line HTTP file server out of the box--but nothing feels extraneous. Lastly, I think it gets close to Knuth's ideal of Literate Programming. Paragraph-length comments thoughout the standard library explain what's happening, how, and why.

For example, the post talks about how io.Copy is awesome. For a concise English explanation, why not go directly to the source!

https://golang.org/src/pkg/io/io.go#L329

[tptacek]

One thing Golang did that was really smart was to have a very slick documentation generator run from unformatted comments, using just a convention for how to write the prose. You have an incentive to write good comments (they're how you document your library to its users), and the comments godoc demands you write also work naturally as comments qua comments.

A lot of Golang is like this: very simple, almost trivial-seeming decisions that potently improve the language in practice. It's a fundamentally simple weapon, it's forged from Damascus steel.

[thomasahle]

For all the comments Go gets on its typesystem, I suppose

    	if rt, ok := dst.(ReaderFrom); ok {
    		return rt.ReadFrom(src)
    	}

Isn't the most terrible way anyone has seen pattern matching implemented.

At least it is better than Java's instanceof + cast.

[zaphar]

For even more similar look to pattern matching look at Go's type switch.

    switch i.(type) {
        case OptionalInterface1:
           // do some extra thing we allow
        case OptionalInterface2:
           // do some other extra thing we allow
    }

It's really good when you have a set of mutually exclusive interfaces or types.

[jerf]

You can do a passable impression of sum types that way too: http://www.jerf.org/iri/post/2917

[arnehormann]

You should use switch v := i.(type) so you can access v as the type in a case.

[benjiweber]

There are other ways in Java

http://benjiweber.co.uk/blog/2014/05/03/pattern-matching-in-...

http://benjiweber.co.uk/blog/2014/08/26/deep-pattern-matchin...

[microtonal]

At least it is better than Java's instanceof + cast.

Except that in a language with generics you have to cast far less, so it is no surprise that Java is less optimized for type casting.

(The primary exception being the equals(Object) method, which most classes should have.)

[thomasahle]

I'm not sure I see how generics help at this particular problem. Functional languages have advanced type systems, but still use pattern matching all the time.

[skybrian]

It certainly looks weird at first, but is there anything objectively wrong with it?

[lmm]

You've missed out a huge sector of programming languages; I'd be more inclined to take your claim of "unique" seriously if you'd included e.g. Haskell or OCaml.

More importantly, it's a massively biased comparison to look at a language from 3 years ago and compare it to those from 20, 30 or 40 years ago. Of course the standard library will be cruftier in an older language. The Idris standard library is beautiful, really state of the art - as you'd expect from a language that's only been written in the last couple of years.

It will be interesting to see what the Go standard library looks like in 20 years' time; I'm betting it will fare less well than Java's, because the workarounds and cruft necessary to avoid breaking changes will be worse in a language without Java's type system. In the meantime, the fair and informative comparison to make is with languages of a similar vintage.

[ExpiredLink]

> Java. A bit better. Compare the readability of OpenJDK's ArrayList.java to the STL vector.h, which does essentially the same thing: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/00cd9dc3c2b5/s.... But of course the Java standard library is immense and has a lot of cruft in it.

Really? Java's success is - rightly - attributed to its simple and usable libraries.

> To write clean Java you really need to avoid much of the standard library (read Effective Java by Josh Bloch)

Lol, the standard ArrayList.java is written by ... Josh Bloch!

[dcposch]

Yeah, ArrayList is fine. I was saying the code is cleaner than its C++ equivalent.

There are many parts of the Java library to avoid. Some are obsolete and terrible, like CORBA or java serialization. Others are gotchas w weird semantics, like Object.clone(). Others are just bad API design--eg the built in IO libs don't require a Charset argument. The default is the "system default charset", which is apparently still the obsolete MacRoman if you're on OSX.

The most annoying are those shortcomings of the std library that cause extra complexity. For example, the built-in JUL logging framework sucks enough that almost everyone uses log4j or logback instead. But now you have user libraries using incompatible logging frameworks. Enter slf4j, a shim that ties them all together.

In my experiemce, Go is a breath of fresh air.

[dead10ck]

Another example of "Wtf were they thinking when they wrote this?" in the Java stdlib is MessageDigest. To build a digester object, you must pass it a string literal to tell it which algorithm to use, and catch a NoSuchAlgorithm exception. Instead of, you know, just using an enum for all supported algorithms.

[crypto5]

I think standard Java library API doesn't know what algorithms are supported on particular platform, additionally you can implement your own messagedigest.

[dead10ck]

They list the algorithms explicitly here:

https://docs.oracle.com/javase/7/docs/api/java/security/Mess...

And here:

https://docs.oracle.com/javase/7/docs/technotes/guides/secur...

[AnimalMuppet]

Right - if I understand correctly, it can depend on what crypto packages are installed on your target.

[crypto5]

> In my experiemce, Go is a breath of fresh air.

Let's see where Go will be in 20 years.