Quite the contrary: NPM's reputation in these circles is less than stellar and it's been incumbent in the JS ecosystem ever since Node became a thing. Well, with a few attempts at competition along the way before those working with the browser jumped on board, but nobody is pushing anybody to use anything but NPM and that attitude hasn't changed for years.
This story isn't unique to Go: both Python and Ruby have had their own ordeals with dependency management, there was an article about CMake just the other day...
Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete.
I don't really know, neither do I know why Javascript is the scapegoat for this kind of shit, it's practically a rite of passage for a language gaining increasing mind-share.
> Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete.
The odd thing is I get the feeling that their search for the one-true system is causing them to repeat every other package manager's mistakes. I'm likely misinformed, but I get the feeling that they think they can do the same thing other package managers have considered or tried, but it will work for them somehow. I don't get the feeling that they seriously considered the criticism of VGo's approach. It smells like hubris. Also, there's Cargo, which is lauded by all, but the proposal doesn't seem to consider that perhaps the Cargo folks had a reason to make their dependency resolution scheme complicated. Again, this smacks of hubris.
I'm happy to be persuaded otherwise, and it would really only take a link to a thread in which some VGo proponent thoughtfully addresses Sam's criticism and the "why not copy Cargo?" criticism (and no, the "Cargo's dep resolution scheme is overly complicated" rationale from the proposal doesn't constitute).
Feels like Go is trying to carve its own path, for better or worse, against conventional wisdom. Plan9 was pretty much the same in a lot of ways and it came up with some really interesting concepts (that sadly haven't panned out that well - I'd love to see a modern OS attempt at Acme, I found that incredibly intriguing and I actually wonder if it could be revived in VR.)
If they come up with something innovative with vgo then great. It's just a shame that the community is opting for a monopoly on the system before it even physically exists. They should be encouraging dep to thrive while doing this experimentation on vgo behind the scenes, because then at least they've got community alignment on dep and not dep, glide, godep, `git clone some-repo vendor/some-repo`, `go get` and whatever else you can do to pull in external code.
> If they come up with something innovative with vgo then great.
For sure, but I actually like Go and I'm unnerved that none of the concerns raised by folks like Sam (read "folks with experience in package management") are being addressed. This approach doesn't inspire confidence in vgo.
This story isn't unique to Go: both Python and Ruby have had their own ordeals with dependency management, there was an article about CMake just the other day...
Maybe Go's mistake is searching for the one-true dependency resolution system and deprecating everything along the way until something good-enough turns up. Maybe it'd be better that developers are encouraged to use dep while vgo is still in proposal stage so that there is an easy migration path from one standard to another, as opposed to immediately rendering obsolete.
I don't really know, neither do I know why Javascript is the scapegoat for this kind of shit, it's practically a rite of passage for a language gaining increasing mind-share.