6 ms·

most wanted: * generics * better package management * gui libraries * better documents

• golergka 10y ago
  I haven't used Go a lot (couple of hobby projects), but found package management to be pretty good. The only thing I could think of is the $GOROOT structure, is this it?
  • diggan 10y ago
    What package management? AFAIK, there is no package management at all in Go, unless you use a third-party tool for doing that. The only thing you can do is fetching the latest revision of some package.
    • themihai 10y ago
      There is an experimental package manaent which most likely will become defaul in Go 1.9
    • geoka9 10y ago
      You can also "vendor", there's support in Go for it.
      • xienze 10y ago
        Which is a poor solution since it involves checking all your dependencies into source control. There's no reason why you shouldn't be able to have a file that lists all your dependencies and versions and lets you pull them down on-demand.
        • geoka9 10y ago
          For sure, I was just pointing out a workaround.
        • prodigal_erik 10y ago
          If you can't build and deploy your own system without a piece of code, you should not be relying on the goodwill of any third party to keep it available for you with no SLA. A good build system is a deterministic function of its input (a commit from your repo) and can run offline.
      • notheguyouthink 10y ago
        Vendor has some very basic problems though, and honestly i think it's unusable due to that. It's a ticking time bomb, imo. In short, types, especially interfaces in returns, are strictly bound to their location which might be a vendor. If two libraries are using vendors[1] then the types are inherently incompatible between the two libraries. My most common point of failure for this is running into Logging interfaces that return themselves. That interface is completely incompatible with the other package's vendored logger, and so you have to have two instances of a logger - one for each package. [1]: (ie, they both have a main package and a library package, so they both have vendors). It's to the point where if you have a main and a library, like many repos, you should simply move the main to another repo entirely.. which sucks, imo.
  • grey-area 10y ago
    It's referring to being able to pin dependencies easily so that you have a stable set of dependencies which is defined. At present go get, while convenient, fetches from head, so things can break when you move computer for example and refetch dependencies, or a new team member comes on board, or if you have an open source project.