3 ms·

> It hugely increases friction for upgrades I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. Yo

> It hugely increases friction for upgrades I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. > have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution By a large margin, I spend the least amount of time configuring my Go packages for release than for any other language.

eropple 13y ago
I can "imagine" a lot of things, too, or I can change one number in a pom or a Gemfile. Because the infrastructure is both predictable and standardized. (And doesn't require barfing your dependencies' changes into your source tree to do it. Funny, that.) "Write a script" is a poor solution for an endemic problem.
- burntsushi 13y ago
  It's not an excuse. As I said, I spend much less time configuring Go packages than I do for packages written in other languages.
  - eropple 13y ago
    Your claim strains my credulity to the snapping point. Please explain how manual operations are faster (and no more error prone than a transitive dependency solver). Bear in mind that it is a one field change in a Gemfile or Composer or Maven/SBT/whatever-Java.
    - tptacek 13y ago
      Bundler and "go get" are an apples/oranges comparison. Gems fetched through bundler are hermetically sealed libraries that live in their own little secret area of the filesystem; when you add a gem dependency to your project, you're extending the platform that you're building code on. Golang's "package" system works more like C's than like Ruby's: when you build a program out of libraries, you have the source to those libraries in a well-known highly-visible place in your build environment. Think of Golang's package management as a refinement of the "codebase/<package>/third-party" idiom in C, and not as an npm/bundler competitor. Golang third-party packages don't work like gems. They are raw code that you build as part of your application. You could build an npm-alike for Golang; I'm not sure how widely used it would be. I like having my third party deps laid out in my repo and easy to read/patch. You can argue that the C third-party idiom is worse than Rubygems, and reasonable people can disagree, but I've had a lot of experience in C (I started my career as a C dev) and a lot of experience with Ruby, and gems have caused me more problems than third-party deps ever have.
      - georgemcbay 13y ago
        "You could build an npm-alike for Golang;" Expanding on this -- There are quite a few dependency management packages for Go already that mimic various other ecosystems, usually written by people who just came to Go from those ecosystems. I can't recommend any because I don't use them because like tptacek I would rather just use a simple repo layout system.
      - eropple 13y ago
        Yeah, I know the differences--I'm using it right now (though I didn't realize it was actually transitive, my bad). I'm straight-up shocked that you say you've had more trouble with gems than source imports; my experience is that it just works (though I have more experience with Java/Scala in Maven than Ruby). I spend most of my time these days in C++ (writing a game), where there's likewise no package management to speak of, and dealing with the slough of git repos (except when it's hg or svn, because reasons) where I have to go find which ones are updated (and then, how), sucks. It's opaque and stupid and takes time out of my day that could be better spent thinking or writing code or hitting myself between the eyes with a hammer. My favorite dependencies in C++ are ones like Boost that I can just get out of Homebrew as a library and come with release notes. (That's rare enough in C++. And maybe I just pick better Java dependencies, but I pretty much always know what changes between Guava 13.0 and Guava 14.0 without vgrepping a bunch of files. Or compiling the world.) This is poking me in a sore spot right now because, as it happens, I'm stuck modifying a client's former consultant's pet Go project right now, written in it because trendy. Stuff is broken in some of his pulled-in dependencies, so I've been trying to update them while actually understanding them which means having my head in vimdiff all day. It's making me want to set fire to things and I'm sorely skeptical of claims that this is easier or takes less time for...well...anybody.
        tptacek 13y ago
        When I add a foreign package to my third-party tree in a C program, I know every time I build the system exactly what version of the code I'm getting. On larger, longer-term projects I've worked on, we've gone through pretty elaborate effort not only to package the third-party code along with our own, but also to carefully manage what versions we're using while hiding that detail from the actual program (so that, for instance, version numbers don't infect the #include directives in the source code). Golang's package system does a good job of streamlining this process, so that as long as you don't try to use it like Rubygems, you can create a reliable build environment for an important program with little effort. Idiomatic bundler, on the other hand --- and, just take my word for it that we've seen a lot of different teams Gemfiles --- treats something like "haml" or "eventmachine" as something akin to a system dependency; versions, when specified, are often fuzzy, like "anything from 1.1.0 to 1.1.9 is acceptable". Ultra-specific versioning in Gemfiles is brittle; a "bundle install" on a mostly-rigid Gemfile can be expected to routinely fail as one gem's dependency on another fails a constraint in the file. There's an upside to the Bundler mechanism, which is that it's very easy to use and doesn't require you to think about the actual code. In fact, Rubygems even hides cross-language dependencies, so that you can easily use libraries that happen to be native C code without even having to know that you're bridging. But there's a downside too, which is that it's opaque and, like I said, brittle. Basically you have to decide whether tracking your upstreams is more important than having a deterministic build. The C programmer in me is obsessed with deterministic builds, and Golang appeals to the C programmer in me, not the Ruby programmer. Again, it's totally legitimate to complain that there isn't a widely-supported npm-alike for Golang. I don't necessarily want one of those, but I can see how a competent programmer would! I'm just saying that it's not reasonable to compare "go get" to npm; they aren't systems with the same goals, even though they sort of look like they are.
    - burntsushi 13y ago
      Have you used the `go` tool before? `go get` handles transitive dependencies. You use that to download your dependencies. From there, it's trivial to check them into your tree and update the import paths. > Please explain how manual operations are faster I said that I spend less time managing package trivia for my Go projects than for any other package. It's not like I spend a lot of time on packages for other languages anyway, but you told me my approach "increased friction." But this is contrary to my experience. It's not like I have a huge problem with how other languages do things. Or even that I think the `go` tool is better. I just know that it works well. So I'm trying to share that experience for people who can't imagine how it might work well.
    - georgemcbay 13y ago
      I'm not the OP you're asking a question of, but agree with the OP's position. In my experience the manual operations required by Go (basically just doing a git/mecurial fork into my own repo and git/mercurial updates as desired) may not be "faster" in the sense of requiring less keystrokes or whatever your measurement is, but it is more predictable and understandable, and not too much "slower". More complicated dependency management systems are great when they work, and then suddenly a huge pain in the ass when they fail in some edge case, the Go way of doing dependency management might require a very tiny bit more effort but pays that off by being much more transparent.
    - frowaway001 13y ago
      Give up ... that person basically lives on HN/other sites to preach his opinion of Go being the best thing ever as the absolute truth. Nothing you can say will change his stance even a single inch. (Yeah. Go's dependency management is so great that people keep writing dozens of wrappers/extensions/replacements. sarcasm)
coldtea 13y ago
>I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. And I can imagine an CSP implementation for C. Should we ditch Go then?
- burntsushi 13y ago
  A CSP implementation for C is likely large and complex. A shell script that runs a few `sed` commands isn't.

eropple 13y ago

I can "imagine" a lot of things, too, or I can change one number in a pom or a Gemfile. Because the infrastructure is both predictable and standardized. (And doesn't require barfing your dependencies' changes into your source tree to do it. Funny, that.) "Write a script" is a poor solution for an endemic problem.

burntsushi 13y ago
It's not an excuse. As I said, I spend much less time configuring Go packages than I do for packages written in other languages.
- eropple 13y ago
  Your claim strains my credulity to the snapping point. Please explain how manual operations are faster (and no more error prone than a transitive dependency solver). Bear in mind that it is a one field change in a Gemfile or Composer or Maven/SBT/whatever-Java.
  - tptacek 13y ago
    Bundler and "go get" are an apples/oranges comparison. Gems fetched through bundler are hermetically sealed libraries that live in their own little secret area of the filesystem; when you add a gem dependency to your project, you're extending the platform that you're building code on. Golang's "package" system works more like C's than like Ruby's: when you build a program out of libraries, you have the source to those libraries in a well-known highly-visible place in your build environment. Think of Golang's package management as a refinement of the "codebase/<package>/third-party" idiom in C, and not as an npm/bundler competitor. Golang third-party packages don't work like gems. They are raw code that you build as part of your application. You could build an npm-alike for Golang; I'm not sure how widely used it would be. I like having my third party deps laid out in my repo and easy to read/patch. You can argue that the C third-party idiom is worse than Rubygems, and reasonable people can disagree, but I've had a lot of experience in C (I started my career as a C dev) and a lot of experience with Ruby, and gems have caused me more problems than third-party deps ever have.
    - georgemcbay 13y ago
      "You could build an npm-alike for Golang;" Expanding on this -- There are quite a few dependency management packages for Go already that mimic various other ecosystems, usually written by people who just came to Go from those ecosystems. I can't recommend any because I don't use them because like tptacek I would rather just use a simple repo layout system.
    - eropple 13y ago
      Yeah, I know the differences--I'm using it right now (though I didn't realize it was actually transitive, my bad). I'm straight-up shocked that you say you've had more trouble with gems than source imports; my experience is that it just works (though I have more experience with Java/Scala in Maven than Ruby). I spend most of my time these days in C++ (writing a game), where there's likewise no package management to speak of, and dealing with the slough of git repos (except when it's hg or svn, because reasons) where I have to go find which ones are updated (and then, how), sucks. It's opaque and stupid and takes time out of my day that could be better spent thinking or writing code or hitting myself between the eyes with a hammer. My favorite dependencies in C++ are ones like Boost that I can just get out of Homebrew as a library and come with release notes. (That's rare enough in C++. And maybe I just pick better Java dependencies, but I pretty much always know what changes between Guava 13.0 and Guava 14.0 without vgrepping a bunch of files. Or compiling the world.) This is poking me in a sore spot right now because, as it happens, I'm stuck modifying a client's former consultant's pet Go project right now, written in it because trendy. Stuff is broken in some of his pulled-in dependencies, so I've been trying to update them while actually understanding them which means having my head in vimdiff all day. It's making me want to set fire to things and I'm sorely skeptical of claims that this is easier or takes less time for...well...anybody.
      - tptacek 13y ago
        When I add a foreign package to my third-party tree in a C program, I know every time I build the system exactly what version of the code I'm getting. On larger, longer-term projects I've worked on, we've gone through pretty elaborate effort not only to package the third-party code along with our own, but also to carefully manage what versions we're using while hiding that detail from the actual program (so that, for instance, version numbers don't infect the #include directives in the source code). Golang's package system does a good job of streamlining this process, so that as long as you don't try to use it like Rubygems, you can create a reliable build environment for an important program with little effort. Idiomatic bundler, on the other hand --- and, just take my word for it that we've seen a lot of different teams Gemfiles --- treats something like "haml" or "eventmachine" as something akin to a system dependency; versions, when specified, are often fuzzy, like "anything from 1.1.0 to 1.1.9 is acceptable". Ultra-specific versioning in Gemfiles is brittle; a "bundle install" on a mostly-rigid Gemfile can be expected to routinely fail as one gem's dependency on another fails a constraint in the file. There's an upside to the Bundler mechanism, which is that it's very easy to use and doesn't require you to think about the actual code. In fact, Rubygems even hides cross-language dependencies, so that you can easily use libraries that happen to be native C code without even having to know that you're bridging. But there's a downside too, which is that it's opaque and, like I said, brittle. Basically you have to decide whether tracking your upstreams is more important than having a deterministic build. The C programmer in me is obsessed with deterministic builds, and Golang appeals to the C programmer in me, not the Ruby programmer. Again, it's totally legitimate to complain that there isn't a widely-supported npm-alike for Golang. I don't necessarily want one of those, but I can see how a competent programmer would! I'm just saying that it's not reasonable to compare "go get" to npm; they aren't systems with the same goals, even though they sort of look like they are.
  - burntsushi 13y ago
    Have you used the `go` tool before? `go get` handles transitive dependencies. You use that to download your dependencies. From there, it's trivial to check them into your tree and update the import paths. > Please explain how manual operations are faster I said that I spend less time managing package trivia for my Go projects than for any other package. It's not like I spend a lot of time on packages for other languages anyway, but you told me my approach "increased friction." But this is contrary to my experience. It's not like I have a huge problem with how other languages do things. Or even that I think the `go` tool is better. I just know that it works well. So I'm trying to share that experience for people who can't imagine how it might work well.
  - georgemcbay 13y ago
    I'm not the OP you're asking a question of, but agree with the OP's position. In my experience the manual operations required by Go (basically just doing a git/mecurial fork into my own repo and git/mercurial updates as desired) may not be "faster" in the sense of requiring less keystrokes or whatever your measurement is, but it is more predictable and understandable, and not too much "slower". More complicated dependency management systems are great when they work, and then suddenly a huge pain in the ass when they fail in some edge case, the Go way of doing dependency management might require a very tiny bit more effort but pays that off by being much more transparent.
  - frowaway001 13y ago
    Give up ... that person basically lives on HN/other sites to preach his opinion of Go being the best thing ever as the absolute truth. Nothing you can say will change his stance even a single inch. (Yeah. Go's dependency management is so great that people keep writing dozens of wrappers/extensions/replacements. sarcasm)

coldtea 13y ago

>I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. And I can imagine an CSP implementation for C. Should we ditch Go then?

burntsushi 13y ago
A CSP implementation for C is likely large and complex. A shell script that runs a few `sed` commands isn't.