5 ms·

I've been hearing this argument for about 4 years now. Pointing out that .NET has terrible dependency management does nothing for me when Google's main language

I've been hearing this argument for about 4 years now. Pointing out that .NET has terrible dependency management does nothing for me when Google's main languages (Python, Java, C++) all have solved dependency management for their own use cases. 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. At the very least they could have continued their hard core hands off approach of allowing the community to solve it. But instead they half-assed it and started capriciously anointing chosen solutions and honestly we're probably in a worse spot than we were before dep came along. Plus, lets be honest here, there's no excuse for constantly changing APIs and binaries. If this was truly about getting the best ideas and lessons learned we'd just see refactors of existing tools with slow migrations to new concepts, but instead we've seen multiple complete rewrites, despite multiple efforts to build common libraries that should prevent such events!

iandanforth 9y ago
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.
- pdeuchler 9y ago
  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.
  - iandanforth 9y ago
    I mistyped. I meant pipenv (https://docs.pipenv.org/ 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.
yarrel 9y ago
Python has several widely-used dependency management systems. C++ has no widely-used dependency management systems. Both languages are doing fine.
- imtringued 9y ago
  Because of the lack of dependency management C++ suffers from "mega dependencies" that include the entire kitchen sink and more.
  - frankzinger 9y ago
    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.
    - pjmlp 9y ago
      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 https://github.com/Microsoft/vcpkg
      - frankzinger 9y ago
        Interestingly, Debian/Ubuntu has standalone packages for most of the boost libs that need to be compiled.
nemothekid 9y ago
>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.
- codetrotter 9y ago
  > 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 https://docs.python.org/3/library/venv.html
- bhaak 9y ago
  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.
  - pjmlp 9y ago
    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.
    - kuschku 9y ago
      Don’t worry, Gradle is moving to kotlin for build scripts already. Groovy will soon be a (failed) thing of the past.
  - vorg 9y ago
weberc2 9y ago
> 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.
- kasey_junk 9y ago
  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.
  - weberc2 9y ago
    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).
    - kasey_junk 9y ago
      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.
ngrilly 9y ago
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.
alien_at_work 9y ago
> 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.

iandanforth 9y ago

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.

pdeuchler 9y ago
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.
- iandanforth 9y ago
  I mistyped. I meant pipenv (https://docs.pipenv.org/ 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.

yarrel 9y ago

Python has several widely-used dependency management systems. C++ has no widely-used dependency management systems. Both languages are doing fine.

imtringued 9y ago
Because of the lack of dependency management C++ suffers from "mega dependencies" that include the entire kitchen sink and more.
- frankzinger 9y ago
  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.
  - pjmlp 9y ago
    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 https://github.com/Microsoft/vcpkg
    - frankzinger 9y ago
      Interestingly, Debian/Ubuntu has standalone packages for most of the boost libs that need to be compiled.

nemothekid 9y ago

>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.

codetrotter 9y ago
> 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 https://docs.python.org/3/library/venv.html
bhaak 9y ago
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.
- pjmlp 9y ago
  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.
  - kuschku 9y ago
    Don’t worry, Gradle is moving to kotlin for build scripts already. Groovy will soon be a (failed) thing of the past.
- vorg 9y ago

weberc2 9y ago

> 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.

kasey_junk 9y ago
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.
- weberc2 9y ago
  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).
  - kasey_junk 9y ago
    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.

ngrilly 9y ago

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.

alien_at_work 9y ago

> 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.