Also it's not that safe, especially if you're using channels, Go could do better than simply panicking when you send to a closed channel. And there is no way to test if a channel is closed.
You can split the implementation of (the methods on) a type over multiple files (and I've seen people do this on GitHub), which can leave you hunting around for the complete definition of a type. Couple this with implicit interfaces and you really are left with a head scratcher. Also there is no "instanceof" operator like in Java, or "conformsTo" method in Objective-C, so if you want to test for conformance to an interface at run-time, you first have to assign the variable to an empty interface and work from there.
There is nothing superior about Go's error handling. Quite the opposite. Write networking code, and you'll soon see that 75% of the code is the same error checking pattern that you can't get away from because of Go's short-sighted view on error handling.
go get has no concept of version pinning. It just pulls straight from the head of a repo. I've seen people resort to embedding what they call "vanity urls" directly in the source code that state the version dependency. To me that is just shocking.
Authored Comments
Smalltalk is not a new language. It's been around for nearly half a century.
https://en.wikipedia.org/wiki/Smalltalk
Also it's not that safe, especially if you're using channels, Go could do better than simply panicking when you send to a closed channel. And there is no way to test if a channel is closed.
https://dave.cheney.net/2014/03/19/channel-axioms
You can split the implementation of (the methods on) a type over multiple files (and I've seen people do this on GitHub), which can leave you hunting around for the complete definition of a type. Couple this with implicit interfaces and you really are left with a head scratcher. Also there is no "instanceof" operator like in Java, or "conformsTo" method in Objective-C, so if you want to test for conformance to an interface at run-time, you first have to assign the variable to an empty interface and work from there.
In terms of performance, it's still way off C:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=…
"superior error handling"? See the section titled "Simplifying repetitive error handling" https://blog.golang.org/error-handling-and-go
There is nothing superior about Go's error handling. Quite the opposite. Write networking code, and you'll soon see that 75% of the code is the same error checking pattern that you can't get away from because of Go's short-sighted view on error handling.
go get has no concept of version pinning. It just pulls straight from the head of a repo. I've seen people resort to embedding what they call "vanity urls" directly in the source code that state the version dependency. To me that is just shocking.