5 ms·

I don't think most people run into this because most backend node programmers have moved to Go at this point, so they're not aware of the upgrade problems. How

I don't think most people run into this because most backend node programmers have moved to Go at this point, so they're not aware of the upgrade problems. How does Go solve this?

phillmv 11y ago
Last time I checked Go didn't really have a package manager, so I think the joke here is that most web apps are semi disposable and people haven't hit the upgrade cycles for their Go apps either.
dham 11y ago
It was just a joke. Just saying that most of the Node developers have probably long since moved to Go.
lobster_johnson 11y ago
Go's static typing goes a long way in helping catch breakage due to things like adding or remove symbols. (However, it does have some warts where incompatible versions may silently compile, like initializers.) While Go doesn't have package management, it does have a framework (go get) for automatically fetching and compiling dependencies. However, people quickly realized that there's no way to pin dependencies; it will always fetch the master branch's HEAD, so if you "go get" a project, it will fetch some arbitary version depending what time of day it is. The community has devised various ways around it, and recent versions of Go have a way of resolving packages to a local "vendor" directory, but it's not a solved problem. There's no solution that stands out from the rest as particularly good or feature-complete when you look at the historical alternatives (Ruby's Bundler in particular).
- paulddraper 11y ago
  Always getting HEAD seems like a rookie mistake that rejects decades of lessons from mature systems and is a real deal breaker. But that may just be me. I think the same thing about generics, and others clearly don't.
  - muraiki 11y ago
    As far as I understand it, always fetching HEAD was the default because Go was developed with Google's giant monorepo full of vendored dependencies in mind, where doing this is both safe and sane. FWIW, I've been using Go 1.5's vendoring alongside govendor and it seems pretty nice. While this situation is a bit of a disappointment given the generally awesome tooling in Go, it's hopefully something that will be resolved soon.
    - kashif 11y ago
      This is the kind of reasoning which bothers me about Go. How can you write a language that you expect the world to use based on assumptions which are only true within 'Google' Brittle.
      - muraiki 11y ago
        Well, I think that it is reasonable to say that the practice of vendoring dependencies is not limited to Google alone. It might not be as common in dynamic languages, but it's fairly common in static languages like C++, which Go was designed to replace. `go get` is basically a better curl for _getting_ dependencies, not _managing_ them. The language authors and the community are addressing the problem of management right now. Before dismissing Go, please try to understand its history and the fact that it is changing.

I don't think most people run into this because most backend node programmers have moved to Go at this point, so they're not aware of the upgrade problems. How does Go solve this?

phillmv 11y ago

Last time I checked Go didn't really have a package manager, so I think the joke here is that most web apps are semi disposable and people haven't hit the upgrade cycles for their Go apps either.

dham 11y ago

It was just a joke. Just saying that most of the Node developers have probably long since moved to Go.

lobster_johnson 11y ago

Go's static typing goes a long way in helping catch breakage due to things like adding or remove symbols. (However, it does have some warts where incompatible versions may silently compile, like initializers.) While Go doesn't have package management, it does have a framework (go get) for automatically fetching and compiling dependencies. However, people quickly realized that there's no way to pin dependencies; it will always fetch the master branch's HEAD, so if you "go get" a project, it will fetch some arbitary version depending what time of day it is. The community has devised various ways around it, and recent versions of Go have a way of resolving packages to a local "vendor" directory, but it's not a solved problem. There's no solution that stands out from the rest as particularly good or feature-complete when you look at the historical alternatives (Ruby's Bundler in particular).

paulddraper 11y ago
Always getting HEAD seems like a rookie mistake that rejects decades of lessons from mature systems and is a real deal breaker. But that may just be me. I think the same thing about generics, and others clearly don't.
- muraiki 11y ago
  As far as I understand it, always fetching HEAD was the default because Go was developed with Google's giant monorepo full of vendored dependencies in mind, where doing this is both safe and sane. FWIW, I've been using Go 1.5's vendoring alongside govendor and it seems pretty nice. While this situation is a bit of a disappointment given the generally awesome tooling in Go, it's hopefully something that will be resolved soon.
  - kashif 11y ago
    This is the kind of reasoning which bothers me about Go. How can you write a language that you expect the world to use based on assumptions which are only true within 'Google' Brittle.
    - muraiki 11y ago
      Well, I think that it is reasonable to say that the practice of vendoring dependencies is not limited to Google alone. It might not be as common in dynamic languages, but it's fairly common in static languages like C++, which Go was designed to replace. `go get` is basically a better curl for _getting_ dependencies, not _managing_ them. The language authors and the community are addressing the problem of management right now. Before dismissing Go, please try to understand its history and the fact that it is changing.