Hacker News Reader

Comment by eternalban | Hacker News Reader

I think it stupid, not merely annoying. In my own projects I have to import "github.com/.." of sibling packages in the same project or go get breaks for my users.

One of the most stupid engineering decisions I've seen in years, imo.

View on HN

It is interesting to me that this feature has evoked such passion and feeling. To me it is a few extra characters and easily managed at the top of a file. It generally will take at least one line of code to import some other package or library. It isn't as terse as say C or C++ nor is it as flexible as Python's import system. Of all the things that bother me about a particular language, this just never bubbled to the surface for me.

(Vendoring and package management are different issues)

It is not a matter of just a few characters. It is a conflation of logical identity (URI) with location (URL). Engineering 101.

https://github.com/coreos/etcd/blob/master/lease/leasehttp/h...

What could possibly justify having to use that import line in a sibling package of the same code?

If you fork a go package with subfolders, you will be in for some trouble. Your fork is still importing the original subpackages, because they are referenced by their absolute (original) address. You don't want to rename the imports in the entire fork because you still want to merge/pull request with the original. So your fork needs to live in a folder that uses the original name, not your fork's name (that local repo will have two remotes, the original and yours). This is a pretty annoying and error prone disconnect, especially for people wanting to use your fork; they need to do the same type of workarounds.

What’s the problem with importing github.com/… in your projects, aside from possibly not being appealing to your personal taste?

The principal question is what is the benefit of this monumental facepalm.

Data provenance.

Now explain your side.

You don't have to change #include paths in C++ (or Java imports) code when you move your project from github to bitbucket.

Have you looked at the build system of a C++ project lately? Or a Java project? It's not like that's some super-elegant not-at-all-rolling-catastrophe of a system.

Java and Node, for example, don't solve anything - to get something that builds sensibly they both entirely depend on "external service" being always available and enforcing naming (see the leftpad fiasco). C/C++ are the source of the term "dependency hell".

I've had to deal with CMake as well as automake/autoconf at work recently and I'll take Go's system of fetching/building any day over the Wild West that is the C/C++ eco-system.

It's an artifact of a tool. The same after-thought tool could have just dropped a mapping line in a .gotool file somewhere:

    $ go get whois etcd
    github.com/coreos/etcd

But no. We need to put that in every freaking file and thus transit from information to noise.

You could ask failed kickstarter projects Haunts: The Manse Macabre what the problem is. Just last week I compiled some 25 year old, K&R style C code and it worked. Will any go code compile in 10 years? 1 year?

https://www.kickstarter.com/projects/2066438441/haunts-the-m...

Vendor it, and your code will always compile.

Reply on news.ycombinator.com