Hacker News new | ask | show | jobs
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.
1 comments

It was pretty bad that easy_install came out with no easy_uninstall. Plus some packages are in your system's package manager (which I think is great because I'm sick of every language having its own package manager when my system's (Gentoo) is better) and some aren't, or the latest versions aren't. Plus there's the virtualenv stuff, or the general problem of your dev environment not matching the deploy environment. Needing to have both Python2 and Python3 on your system in some cases. Some packages have C/C++ code so you need a compiler, and all the dependencies that implies. On Windows I think Python development is a joke, last time I did anything extensive there I think I ended up installing Enthought's distribution and picked off from http://www.lfd.uci.edu/~gohlke/pythonlibs/ as needed. I don't see how the Go situation on Windows could be worse than that.

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.