4 ms·

Go's import system has tons of problems. 1) inconsistent syntax: import "github.com/fsouza/go-dockerclient"; docker.NewClient... Notice how you import somethi

by TheDong 11y ago

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) init side effects, e.g. look at how pprof works. Literally you do an underscore import and it mutates the behaviour of the http package. Thanks.

Vendan 11y ago
1) Yes, that is messed up, but that's just cause that package isn't following standard idiom 2) Build flags are very useful, on the verge of required, for some situations. For instance, code that needs seperate implementations for each os. 3) This is very useful for packages that may be on github, but served through an alternate path. If they import the github version, you are now stuck with github. If you move to self hosted git or something, their existing codebase won't know how to do an update, and will require a rewrite to use the new version. 4) I'll be the first to admit it isn't the greatest, but, it's rendered mostly moot by the fact that you build single binaries. Deal with a slightly annoying import system in exchange for effortless deployments and not having to worry about libraries and such on the servers? Heck yeah! 5) I agree on this one, it should be something more like doing pprof.Register(*ServeMux) in an init in your program.

by TheDong 11y ago

Vendan 11y ago

1) Yes, that is messed up, but that's just cause that package isn't following standard idiom 2) Build flags are very useful, on the verge of required, for some situations. For instance, code that needs seperate implementations for each os. 3) This is very useful for packages that may be on github, but served through an alternate path. If they import the github version, you are now stuck with github. If you move to self hosted git or something, their existing codebase won't know how to do an update, and will require a rewrite to use the new version. 4) I'll be the first to admit it isn't the greatest, but, it's rendered mostly moot by the fact that you build single binaries. Deal with a slightly annoying import system in exchange for effortless deployments and not having to worry about libraries and such on the servers? Heck yeah! 5) I agree on this one, it should be something more like doing pprof.Register(*ServeMux) in an init in your program.