6 ms·

Isn't the way Go handles dependencies just as crazy? Not trying to troll here, but I don't think Go has an excellent track record in that area either.

zaarn 8y ago
I do a lot of go development and while it's not the most sane environment atm, there are solutions and the ecosystem makes it less of a problem. Breaking API compatibility is something that happens very rarely (I think I had to fix up applications of mine about once a year because some dependency changed), most packages with active development are very mature. Additionally we have tools like dep and (soon) vgo that allow you to vendor and pin certain dependencies at certain versions (you can do it manually too, /vendor/ is where go looks first for any dependencies so you can replicate "dep init" by copying all dependency paths in your gopath into /vendor/) There is also less "make a package for everything", packages tend to have much broader feature scope. is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package.
- egeozcan 8y ago
  > is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package NPM does have an extra use case: Web development. Tree shaking in JS-land is still far from perfect and people don't want to (more like, are asked to) send as little as possible over the wire. So, different use cases, different trade-offs.
  - zaarn 8y ago
    Yes but go can do tree shaking and will not include packages in the binary that aren't used (that also means parent packages if a subpackage does not reference those). I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering. Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step
    - egeozcan 8y ago
      > I'm not sure what is stopping NPM or Yarn from doing this at least in the packaging step You had already answered that on your previous sentence :) > go can do tree shaking and will not include packages in the binary that aren't used Again, different languages, different trade-offs. JS isn't statically compiled. This is a much harder problem to solve for JS. I'm talking from personal experience when I say that it still isn't completely solved (requires ES2015 module syntax and has many assumptions). Even Go has hard-time optimizing-away some code because of its limited type system.
      - zaarn 8y ago
        Go isn't limited by the type system per se. IIRC from the various papers on the matter, the only real way to get Go to stop dropping unused functions is to use the runtime and reflection packages since then Go can't tell what functions might be used and fields accessed. Though also IIRC the go compiler is decent at localizing this instead of stopping all optimization. >You had already answered that on your previous sentence :) Yes but NPM/Yarn should be capable of atleast dropping packages that can be statically proven to not be imported. That means if a package imports require("xy-" + variable) then you'll have to be clever but if a package consists only of static imports then you can shake a lot.
egeozcan 8y ago
Go didn't have any significant track record until glide came. But it still doesn't have a central repository so every update check means querying all the individual repositories, chokes sometimes on hg repositories, takes tens of seconds even with a few dependencies... I also don't like how all people became "X developers". We are software developers. I don't think anyone who can code JS would have difficulty switching to Go or vice versa (unless you are a mostly non-technical person, probably from marketing, who learned just enough jQuery, something which I also respect - I never learned just-enough marketing).
movedx 8y ago
The mentality I see around Go development in general is: what does that dependency you're bringing in do and why do we need it? The tooling is irrelevant. It's about how it's all brought together and used.

zaarn 8y ago

I do a lot of go development and while it's not the most sane environment atm, there are solutions and the ecosystem makes it less of a problem. Breaking API compatibility is something that happens very rarely (I think I had to fix up applications of mine about once a year because some dependency changed), most packages with active development are very mature. Additionally we have tools like dep and (soon) vgo that allow you to vendor and pin certain dependencies at certain versions (you can do it manually too, /vendor/ is where go looks first for any dependencies so you can replicate "dep init" by copying all dependency paths in your gopath into /vendor/) There is also less "make a package for everything", packages tend to have much broader feature scope. is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package.

egeozcan 8y ago
> is-even and is-number would most likely become part of a bigger package concerned with mathematical operations and helpers or a datastructure package NPM does have an extra use case: Web development. Tree shaking in JS-land is still far from perfect and people don't want to (more like, are asked to) send as little as possible over the wire. So, different use cases, different trade-offs.
- zaarn 8y ago
  Yes but go can do tree shaking and will not include packages in the binary that aren't used (that also means parent packages if a subpackage does not reference those). I'm mostly pointing out that despite vanilla go's complete lack of version pinning, the community has (had to necessarily) step up and solve this by engineering. Tree Shaking in JS should be trivial if the parent package implements no code and imports should be easy if they aren't of a dynamic nature (ie, "require('package/' + variable)") I'm not sure what is stopping NPM or Yarn from doing this atleast in the packaging step
  - egeozcan 8y ago
    > I'm not sure what is stopping NPM or Yarn from doing this at least in the packaging step You had already answered that on your previous sentence :) > go can do tree shaking and will not include packages in the binary that aren't used Again, different languages, different trade-offs. JS isn't statically compiled. This is a much harder problem to solve for JS. I'm talking from personal experience when I say that it still isn't completely solved (requires ES2015 module syntax and has many assumptions). Even Go has hard-time optimizing-away some code because of its limited type system.
    - zaarn 8y ago
      Go isn't limited by the type system per se. IIRC from the various papers on the matter, the only real way to get Go to stop dropping unused functions is to use the runtime and reflection packages since then Go can't tell what functions might be used and fields accessed. Though also IIRC the go compiler is decent at localizing this instead of stopping all optimization. >You had already answered that on your previous sentence :) Yes but NPM/Yarn should be capable of atleast dropping packages that can be statically proven to not be imported. That means if a package imports require("xy-" + variable) then you'll have to be clever but if a package consists only of static imports then you can shake a lot.

egeozcan 8y ago

Go didn't have any significant track record until glide came. But it still doesn't have a central repository so every update check means querying all the individual repositories, chokes sometimes on hg repositories, takes tens of seconds even with a few dependencies... I also don't like how all people became "X developers". We are software developers. I don't think anyone who can code JS would have difficulty switching to Go or vice versa (unless you are a mostly non-technical person, probably from marketing, who learned just enough jQuery, something which I also respect - I never learned just-enough marketing).

movedx 8y ago

The mentality I see around Go development in general is: what does that dependency you're bringing in do and why do we need it? The tooling is irrelevant. It's about how it's all brought together and used.