Comment by swagonomixxx | Hacker News Reader

Comment by swagonomixxx | Hacker News Reader

> Does your organization manage their own internal go documentation server (similar to godoc.org)? > No (85%)

I would be very open to setting this up at my org - is there a canonical way to do this?

> What is the biggest challenge you personally face using Go today? > Working with modules / vendoring / pkg mgmt 12%

Go has come a long way since the solutions in the early days and is now supremely better than it every was. However, vendoring is still confusing, and it's unclear when one should commit vendor files (we did that at one of the places I used to work) and when one shouldn't. We kept getting afraid that one day some guy would just delete that repo off GitHub, or somebody would end up hacking it, then we can't get an important fix out into prod. I'm not sure if the Go team has any advice regarding this.

> What is the biggest challenge you personally face using Go today? > Issues with tooling 12%

I think Go in general has become very mature. From a tooling standpoint it's almost feature complete. The only thing I would like to see there is better autocomplete and tooling around calling C from Go but I know that's kind of hard to achieve. I frequently work with C libraries that I have to call from Go because Go is simply easier to write than C, but I don't think that Cgo has good integration with gopls at the moment (and I don't think it did in any other tooling that I've used).

RE: modules and vendoring, you should no longer have to worry about a package going away now that proxies have been introduced (the default proxy right now being proxy.golang.org).

You should be able to pull all your modules from a proxy, minus any private repos you control (which you can either setup our own proxy for OR set The GOPROXY var to go direct to vcs for it).

Also, not vendoring should give you a smaller repo and build speed shouldn’t suffer too much (proxy caching and such).

Ah good point about GOPROXY.

So if I have a mix of private and public dependencies that I pull in, can I specify a specific proxy for the private ones? Is it the GOPRIVATE env var?

The proxy should maintain a copy of all dependencies (public and private), so only one should be necessary.

This should be clarified, if you setup YOUR OWN proxy it can handle both public and private modules (side note I haven’t been able to verify this yet with artifactory).

You can also just let your GOPROXY fallback go “direct” which will then go straight to vcs (you need to make sure you have a gitconfig setup to redirect https to ssh).

modules and vendoring is still a pain and I don't want or need a network resource to build my code. If a vendor directory is present, use it!

While things are better in Go 1.14, it is not solved. I do not want to set up a company proxy for our private repos. I can't count how many times some combination of GOPROXY, private repos, vendoring, and modules have been a problem.

re: Setting up internal go documentation server - the godoc package has great instructions for doing so!

https://godoc.org/golang.org/x/tools/cmd/godoc

Reply on news.ycombinator.com