41–50 of 117 posts
The biggest blocker in getting me to give Go a shot is it forcing a certain directory structure on me, and the lack of Gemfile or package.json equivalent. Has this been solved? I really want to use Go because of everything I've heard, but I can't stand how $GOPATH forces a directory structure on me.
Nice summary. The biggest pain with Go is the dependency management. I initially started to commit the whole vendor folder for each project, but lately I only commit the Gopkg.lock and Gopkg.toml Both those approaches bothered me over time and I'm still undecided about what's the best way to do this. I know some projects only commit their Gopkg.toml (and not lock) with some explicit dependencies.
* GOPATH is going to go away soon. Once vgo gets fully baked in to the language. Probably by 1.12 - https://github.com/golang/go/issues/4719.
* There is a one-line installer called "getgo" which installs Go. However, it needs further polish which is being worked on - https://github.com/golang/go/issues/23381, https://github.com/golang/go/issues/21277.
I was expecting a way to organise a golang folder structure for web apis (2018), as there are some old tutorials out there
github.com//
|- main.go
| |- config/
| |- db/
| |- server/
| |- router/
| |- handler/
| | |- get/
| | |- put/
etc.
At various points you'll probably find that sub-packages become general enough that they can be easily broken out into their own repos and maintained separately. This can wind up being a good goal to shoot for when designing the APIs for each sub-package.
`dep` is actually a good tool and suppose to be the official tool. But out of no reason, `vgo` came out and said to be deprecating `dep`. I don't really understand how the Go team make decisions.
> Go dependencies are a little odd the first time you run into them. I suspect this is because Google runs a mono-repo and as such the decisions around it were made with that in mind. I think the oddness is around the directory structure. It may also be because Go was developed by UNIX old hands. When UNIX was designed, it was not just for ordinary users, but also developers. When developing in UNIX, you can use all…
What exists in the public world of go was simply what the go team wanted for go and not a compromise to fit in with other systems at Google. I think the fact that you end up with what looks like a monolithic repository is just a coincidence.
In the end ~/go doesn't look a lot different than the @INC path that points to something in your home directory, or /usr/include, /usr/lib, and /usr/bin in a pure C system. It's just the fact that you also put your own code in the same directory as third-party packages that confuses people... but in the end, someone else will consider your package a third-party package someday... so I don't think there's much value in treating it any other way.
Earlier quoted context omitted.
> forced the developer to adopt a specific folder organization Well, so does C (and basically everything else). Alternatively, you can pass tons of -I and -L flags to your compiler calls but you can do that with Go, too. The point of GOPATH was to make this unnecessary because everything can be deduced from the source code and its location within the file system.
You have it backwards. C doesn't restrict where I can keep my source tree.
"Set that up manually" usually consists of an m4 script that takes 15 minutes to run as it tries to look for all the dependencies ("./configure"). It's flexible, but it's not great.
If you're using Go with Docker 17.05 or higher, I recommend a multi-stage Docker build. Official documentation here: https://docs.docker.com/develop/develop-images/multistage-bu... The default Go Docker images include everything needed to compile Go. But once you have a binary, you really only need an image capable of running your binary. I've seen images sizes reduced by over 95%. Revising the example in the article…
I've been using `scratch` final builds .- FROM golang:1.10 WORKDIR /go/src/bitbucket.code.company-name.com.au/scm/code COPY ./ ./ RUN CGO_ENABLED=0 go build -a -installsuffix cgo -o /dist/main . FROM scratch COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ COPY --from=0 /go/src/bitbucket.code.company-name.com.au/scm/code/dist/main / ENTRYPOINT ["/main"] It requires a bit more "magic", but is a smaller…
> Go dependencies are a little odd the first time you run into them. I suspect this is because Google runs a mono-repo and as such the decisions around it were made with that in mind. I think the oddness is around the directory structure. It may also be because Go was developed by UNIX old hands. When UNIX was designed, it was not just for ordinary users, but also developers. When developing in UNIX, you can use all…
/Usr/src within the Linux community hasn't really been a normal thing for many many years.
Go certainly has old hands involved and the /usr/src example makes sense, but the context is one requiring years of knowledge.
`dep` is actually a good tool and suppose to be the official tool. But out of no reason, `vgo` came out and said to be deprecating `dep`. I don't really understand how the Go team make decisions.