Hacker News Reader

>when Google's main languages (Python, Java, C++) all have solved dependency management for their own use cases.

Huh? Of those three, I would only consider Java "solved", and both Maven & Ant are far from the panacea of package management.

virtualenv is a community project (much like dep), is pretty new in the grand scheme of things, and isn't completely standardized (some projects use tox, some list out requirements.txt (rarely version pinned), and others vendor.

As for C++, almost everyone does something a bit different so I don't see how that is at all relatable.

> virtualenv is a community project (much like dep)

virtualenv was a community project but based on that venv was created and has been part of the official Python distribution since Python 3.3, released in 2012.

https://docs.python.org/3/library/venv.html

For java, I would look at gradle, not maven.

Of course, gradle hooks into the whole maven ecosystem but that is one of its advantages. Everybody in Java land understands Maven packages but how you generate doesn't matter.

Android builds have renewed by love for Maven.

If it wasn't for Android, I wouldn't bother 1 second to learn Gradle.

But I guess Groovy needs some project to keep it alive, now that no one remebers the days JSF beans would be written in Groovy or JUGs were holding Grails talks month after month.

Don’t worry, Gradle is moving to kotlin for build scripts already. Groovy will soon be a (failed) thing of the past.

Seems like every other site is converting its Gradle builds into Bazel.

Gradle degraded the dependency experience significantly from maven. Maven had a deterministic, sensible (and selectable) way of dealing with conflicts - gradle just defaults to "largest version wins". Similarly, gradle chucked the whole idea of being able to manage common sets of dependencies across multiple projects easily (the maven super pom). I mean, it's all programmable in gradle, but it pretty much ignored the excellent work maven had done except to use its repos.

>virtualenv is a community project (much like dep)

It doesn't stop there either I've seen python projects using nothing, virtualenv, venv, pip-tools, and pipenv.

I finally feel like pipenv is the true solution and it seems very new. All that said and Python is quite old relative to Go.

Python is slowly catching up. For example in JS/Elm/Rust you have a clean approach with:

* a central package registry

* a file to describe dependencies

* a command line tool to install, build and publish packages

In Python things are more fragmented. You have:

* a central package registry

* a file to store some of your dependencies (Pipfile)

* a command line tool to install packages (Pipenv)

* a file called setup.py in which you need to specify your dependencies again (in another format). You can execute this file to build/publish packages.

It think it would allow for a much nicer user experience if pipenv/pipfile would handle packaging/building/publishing as well..

With all the bad press npm has had, I would not put it in the clean approach bag.

Python has several widely-used dependency management systems.

C++ has no widely-used dependency management systems.

Both languages are doing fine.

Because of the lack of dependency management C++ suffers from "mega dependencies" that include the entire kitchen sink and more.

Which C++ projects have "mega dependencies"? There is no technical reason to have those (or any other kind of dependency management problems, for that matter). I'm not sure what it's like on Windows, but most other OSes support all of the major C++ dependencies in their default package managers (or things like MacPorts on Mac OS) and it's not difficult to install anything else manually.

I think he/she means something like boost or Qt.

On Windows, Microsoft is investing on vcpkg as package manager.

https://github.com/Microsoft/vcpkg

Interestingly, Debian/Ubuntu has standalone packages for most of the boost libs that need to be compiled.

You don't think Python also has thrash? I'm a huge fan of pyenv as it brings in manifest+lockfile+segregated install paths. But those three things are relatively new to Python and very new to get unified.

environment namespacing != dependency management

Regardless of your setup at the end of the day you're using pip to solve your dependency graph, and have been for over a decade.

I mistyped. I meant pipenv (https://docs.pipenv.org/) not pyenv. Pipenv does use pip but is a significant, recent upgrade to package management and is now the recommended tool.

There is only 24 hours in a day, and the Go team has limited resources. They focused on other issues in the last few years. Dependency management is the current focus now.

> If the Golang team has had enough time to cherry pick the best ideas and lessons learned to build a language

Except where have they done that? They've had 40 years and their solution to the C binary function error code return problem was... to add a special way to return an error code. There have been superior solutions to this for 20 years at least.

How long have we known about the value of generics?

To me, the fact that they can't figure out how to solve this isn't remotely suprising.

> If the Golang team has had enough time to cherry pick the best ideas and lessons learned to build a language they've had enough time to do so for dependency management.

Most of Go's features are those that proved their value over 40 years. There are no dependency management schemes that have that kind of reputation. Good ideas take time and misfeatures are expensive.

CSP the central premise of golangs concurrency model doesn’t meet that bar.

If they are willing to throw out that requirement for something as fundamental why should dependency management be held to so high a standard.

Not sure what you're referring to. CSP turns 40 this year, and it's not the central premise of Go's concurrency. Whatever the original intent, very little Go is written in true CSP fashion. Of course, even if I were wrong about these points (and I'm not), it wouldn't invalidate my original point as you suggest: just because most of Go's features are very old doesn't mean Go is forbidden from making an innovative move or two--for example, its scheduler is unprecedented (at least as far as I'm aware).

Something being formulated exactly 40 years ago in academia doesn’t count as proving its value over 40 years especially given that broad support of the concept is new being supported by golang and at best the marginally popular clojure. The golang faq specifically says that csp is the basis of its concurrency.

Combine those 2 facts & I think it’s fair to say golang is willing to base things (central ones even) on untried ideas, which directly contradicts your stated position which was precisely that no dependency management scheme lives up to the precedent of the other accepted features of the language.

This is trivially proven incorrect via looking at other language dependency management schemes that have much more broadly proven their worth.

> doesn’t count as proving its value over 40 years

The Go designers used CSP over the course of many decades via Newsqueak, Alef, Limbo and Plan 9 C's libthread.

As only a go user & not a contributer, that describes more the paradigm I’ve observed for how golang chooses the features to add.

Did the principles enjoy a feature while using it on Plan 9? Likely to be included. A feature having broad industry or academic backing, or a long history? Immaterial.

Newsqueak, Alef, Limbo and Plan 9 C's failed spectacularly in the market, nothing to brag about as proven technologies.

In fact, as nice as Go might be, if it had the AT&T Research Labs stamp instead of Google's, it would been just as successful.

> Combine those 2 facts & I think it’s fair to say golang is willing to base things (central ones even) on untried ideas, which directly contradicts your stated position

It absolutely doesn't contradict my stated position. I was clear about that in my previous post.

CSP inspired Go's features (in that sense alone it is "the basis for Go's concurrency" as alluded to by the Go FAQ) , but as I mentioned, it's not integral to Go in any way, and very few programs are modeled in CSP fashion.