7 ms·

Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. Are you kidding me??? So if some inva

• wtetzner 12y ago
  Yeah, this seems crazy to me. Also, honestly, while stable APIs can be nice, I would rather have people have the option to change the API in later versions, if it makes things better. But I want to be able to consciously decide to upgrade when I'm ready.
  • enneff 12y ago
    You do have that option. As I explained at the time (but this was not included in the live blog), the convention is to change the import path when the package API changes.
• enneff 12y ago
  If you're shipping serious code you should be vendoring your dependencies.
  • munificent 12y ago
    Why?
    • namsral 12y ago
      Because you want to have control over all software you're shipping to production.
      • simoncion 12y ago
        If "vendoring" precludes one from using a dependency installed on the system, then this practice is static linking all over again. Static linking has its place, but dynamic linking with sane versioning solves many problems.
        • dangerlibrary 12y ago
          I'm pretty sure all Go binaries are statically linked.
          • weitzj 12y ago
            But they said there are plans for dynamic linking
          • munificent 12y ago
            Sure, but that's orthogonal to what's being discussed here. You don't check your compiled binary into source control, but proponents of vendoring do check their (transitive) dependencies in.
        • kyrra 12y ago
          People like Go because you have a single executable to drop on a box, no worrying about what version of what libraries are installed. Though, the Go team realizes there is a need for dynamic linked libraries, so they at least have a proposal for it[0]. [0] https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit# https://docs.google.com/document/d/1nr-TQHw_er6GOQRsF6T43GGh...
          • 23david 12y ago
            I've been following that proposal, and I'm a bit surprised that it isn't mentioned on the roadmap. Looks like dynamic linked libraries will come sometime in 2.x land?
            • kyrra 12y ago
              One of the other talks made reference to it[0]. [0] http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-dependency-management-design-philosophy http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-de...
      • munificent 12y ago
        Sure, but manual vendoring is just one (tedious, error-prone) means to that end. Any sane package manager with something akin to lockfiles gives you the same guarantee without all of the headaches of vendoring (and unvendoring when no longer needed!) all of your transitive dependencies.
        • enneff 12y ago
          It's not tedious or error prone. Just use the tool.s
  • jbooth 12y ago
    So, uh, why is the go-supported option encouraging me to download it from github at compile time without so much as crude versioning support? Lots of people run internal Maven repos, they have every dependency vendored, but they also want the ability to choose between versions of that dependency.