|
|
|
|
|
by lelandbatey
3506 days ago
|
|
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: $ cd $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. |
|
I'm not a huge stickler for non-local consistency -- one of the things I like about Nim is its apathy about naming conventions (foobar is the same symbol as foo_bar or fooBar, func(arg) is the same as arg.func()...) -- so that's probably why I don't find the consistency factor a huge issue. When a language and its ecosystem has it, it's nice, but when it doesn't, it's not really a thing that annoys me.