LElelandbatey·Nov 10, 2016
For me, it's the extremely straightforward conventions of Go, with it's straightforward tooling, and it's strong typing.
I "grew up" on Python, wrote a lot of code in it, and love it. But it doesn't feel as cohesive as Go.
As an example of cohesive tool design, let's look at Go package management. In Go, if I want to install a package, I install it with:
$ go get github.com/pkg/term
Having installed this package, I import it in my code with:
import "github.com/pkg/term"
Having imported this package, I'd like to read the documentation for it. To do that I use the command `go doc` with the package name:
$ go dock github.com/pkg/term
Now that I've read the docs, I've got a question about how some particular
functionality is implemented. With Go, I happen to know exactly where I can
read that code, on my own hard drive:
$ c
Read the rest
d $GOPATH/src/github.com/pkg/term
With Python, I find that I don't have this absolute guarantee of consistency.
Usually, packages will have a similar convention, but some require installing
with one name and importing with another, and the local documentation viewer
(pydoc) isn't installed by default, so I didn't even know about it until
relatively late in my use of Python. I've had a similar experience with the
rest of Python's tooling: it's as feature complete or better than Go's, but
it's not quite as consistent as Go.