go-dockerclient

Go's import system has tons of problems. 1) inconsistent syntax: import "github.com/fsouza/go-dockerclient"; docker.NewClient... Notice how you import something with the trailing path being "go-dockerclient" but the actual package name is "docker"? In npm, if you type x = require("foo"), you always refer to it as 'x.something'. You don't have to guess or read docs. 2) build flags. What the fuck? // +build fuckme 3) Canonical import paths. Double what the fuck? For those of you who don't know, if you have "github.com/foo/bar" but write 'package bar // import "github.com/google/bar"' then a user of your package will not be able to compile it unless they move it to the directory you gave. Yeah, no joke.... I'm in awe at this stupidity 4) Poor project-based importing (something actually worse than virtualenv; nothing near as good as npm). 5)

Hm, I agree that github CR is not good. Glaf they're using Issues though as Github discussions are a _really nice_ way to build software. I personally find Gerrit painful to use, but has critical features, as enneff described. Hope Github really steps up to the plate. Also, everyone who uses github whould really check out *Sourcegraph's code review stuff. They show you really useful things like: - exactly what definitions were added/removed/changed (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) - a diff with jump-to-definition links (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) - a list of people and projects impacted by the change (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...) Totally gets rid of the "understanding the PR diff" problem others mentioned

Yes times 1,000! This is what we're trying to address at Sourcegraph (https://sourcegraph.com/). 80% of programming is about reading and understanding code, not writing code. Why don't existing tools focus more on helping people read and understand code--and, more broadly, collaborate on a development team? Things like: * seeing everywhere a function or class is used, in context (like https://sourcegraph.com/github.com/joyent/node/.CommonJSPack... on the right side) * seeing who at your company knows the most about an area of your codebase * seeing the history of changes, in terms of functions/modules added, not just lines (like https://sourcegraph.com/github.com/fsouza/go-dockerclient/.c...) * having a long-lived discussion about a module/class/function that doesn't vanish after a commit is merged or the file's lines shift around So far,