Hacker News Reader

Comment by twblalock | Hacker News Reader

Have other platforms done this? I'm having trouble thinking of a language toolkit that has dependency management built by the core team. All of these solutions are third-party, they have just become the de-facto standard:

Java uses Maven or Gradle: third party

Python uses pip: third party

Ruby uses gems: third party

Node.js uses npm: third party

I'm sure I'm missing some, but this seems to be the norm. Go just hasn't been around long enough for a single third-party solution to become the de facto standard.

View on HN

I think this is something of a shibolleth for a certain type of programmer:

* Thinks that dependency management of third party libraries is an important problem in their project.

* Demands that there be one centralized repo and method for that. No alternatives!

Maybe it shows that I am a C fan, but I kind of skew on the opposite of this spectrum. Really the most important part of your project is how you import a library? Really? Even out of chaos, like a language with no native support for it, it's a small chore and you get over it quickly. But I am not one of the types that agonizes over it, as I guess go people are.

I'm a C fan, too, but not when it comes to dependencies. In a world where using someone's library typically requires one or more of (a) having everyone compiling your code also manually compile the library, (b) hoping the library has found its way into N different OS package managers, and (c) vendoring requiring manual maintenance, you end up with a lot of real world C and C++ code reimplementing basic things that would be better done in a library, because importing a library is too much work. This sucks - certainly it's possible for libraries to be too small, dependency graphs too convoluted, and you can see some of that on npm, but C/C++ are so far on the other end of the spectrum that it's hardly worth thinking of.

Not trying to say it isn't painful, just that people live with it and are still productive. And by not mandating a single one you get several experiments. Autoconf could be one. pkg-config another. The *bsds do interesting things with a particular dialect of makefiles. Even Microsoft has a few: the wdk build system, vs/msbuild, nmake... All of these have ups and downs but few of them are outright "wrong", we live with them and I wouldn't want to see any one mandated...

What's wrong with reimplementing basic things? Dependencies are points of fragility; I'm happy to pay a little extra redundancy in exchange for greater resilience.

> I'm having trouble thinking of a language toolkit that has dependency management built by the core team.

Rust + Cargo.

Ceylon + Herd

> Python uses pip: third party

FWIW pip is now bundled with Python unless specifically unbundled (e.g. by linux distros)

Scala + SBT. Best thing ever.

Reply on news.ycombinator.com