5 ms·

I'd say Go is the benchmark in case of import system. - consistent syntax - no circular dependencies - you can only import a module, only one symbol is polluti

by lukasm 11y ago

I'd say Go is the benchmark in case of import system. - consistent syntax - no circular dependencies - you can only import a module, only one symbol is polluting the namespace I wonder what will be the winning solution for versioning. npm and 260 char limit for path on Windows was driving me nuts.

Vendan 11y ago
note, Go does allow namespace pollution via dot imports, though they are ill-regarded by most of the community.
pcwalton 11y ago
> I'd say Go is the benchmark in case of import system. I prefer systems that (a) allow namespace nesting within a single package and (b) don't run arbitrary code on import (in Go's case, init()). The latter is particularly pernicious because systems that have arbitrary code execution on import have to define some kind of global ordering on imports (throughout the entire program!), since the order that packages get loaded in very much affects the program semantics. This is called the "static initialization order fiasco" in C++ and Go inherits it too.
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.
madeofpalk 11y ago
> npm and 260 char limit for path on Windows was driving me nuts. If you can upgrade, node 5/npm 3 fixed the by flattening out the node_modules folder as much as possible.
- toupeira 11y ago
  "As much as possible" would be doing node_modules/$PACKAGE-$VERSION for all packages (like e.g. Rubygems does). But instead they're doing node_modules/$PACKAGE and still nesting conflicting dependencies, so it's entirely possible to still run into the same issue.

by lukasm 11y ago

Vendan 11y ago

note, Go does allow namespace pollution via dot imports, though they are ill-regarded by most of the community.

pcwalton 11y ago

> I'd say Go is the benchmark in case of import system. I prefer systems that (a) allow namespace nesting within a single package and (b) don't run arbitrary code on import (in Go's case, init()). The latter is particularly pernicious because systems that have arbitrary code execution on import have to define some kind of global ordering on imports (throughout the entire program!), since the order that packages get loaded in very much affects the program semantics. This is called the "static initialization order fiasco" in C++ and Go inherits it too.

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.

madeofpalk 11y ago

> npm and 260 char limit for path on Windows was driving me nuts. If you can upgrade, node 5/npm 3 fixed the by flattening out the node_modules folder as much as possible.

toupeira 11y ago
"As much as possible" would be doing node_modules/$PACKAGE-$VERSION for all packages (like e.g. Rubygems does). But instead they're doing node_modules/$PACKAGE and still nesting conflicting dependencies, so it's entirely possible to still run into the same issue.