It feels like a slight failure that things like this are necessary, especially for a new language. As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. However Go has 19 years on Python. I understand that they are different languages and ostensibly serve different purposes, but it feels like a shortcoming to me - based on the little Go experience I've had.
> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.
How to start a Go project in 2018
21–30 of 117 posts
Re: How to start a Go project in 2018
#22If 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…
Re: How to start a Go project in 2018
#23Earlier quoted context omitted.
I don’t like a lot of Go features but the GOPATH system is really quite good (until you care about pinning versions, when it becomes not worse than Python).
GOPATH is going away with vgo so it wasn't really good at all as it forced the developer to adopt a specific folder organization. The fact that go maintainers acknowledged this issue is a sign they are ready to move the language forward.
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.
Re: How to start a Go project in 2018
#24Re: How to start a Go project in 2018
#25It feels like a slight failure that things like this are necessary, especially for a new language. As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. However Go has 19 years on Python. I understand that they are different languages and ostensibly serve different purposes, but it feels like a shortcoming to me - based on the little Go experience I've had.
> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.
Re: How to start a Go project in 2018
#26Earlier quoted context omitted.
> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.
It's still a bit new, but I think pipenv [1] is the new standard now. No need to directly work with pip or virtualenv anymore, and the equivalent requirements file works more like npm/yarn. [1] https://github.com/pypa/pipenv
C++, though, still a mess to get an isolated build environment there. Meson and Bazel are close, so close...
Re: How to start a Go project in 2018
#27If 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…
You can remove CGO_ENABLED=0 by using the Go Alpine image (golang:1.10-alpine). The issue is caused by Alpine images being musl libc based.
edit
I misunderstood the parent, they meant to use `golang:1.10-alpine` as the build image, not the run image, as in:
FROM golang:1.10-alpine
COPY . /go/src/bitbucket.code.company-name.com.au/scm/code
WORKDIR /go/src/bitbucket.code.company-name.com.au/scm/code/
RUN go build main.go
FROM alpine:3.7
RUN apk add --no-cache ca-certificates
COPY --from=0 /go/src/bitbucket.code.company-name.com.au/scm/code/main .
CMD ["./main"]
Which works! Thank you!Re: How to start a Go project in 2018
#28Earlier quoted context omitted.
You can remove CGO_ENABLED=0 by using the Go Alpine image (golang:1.10-alpine). The issue is caused by Alpine images being musl libc based.
Using the `golang:1.10-alpine` image to run your binary would defeat the purpose of a multi-stage build, since it includes everything needed to compile Go and weighs in around 376MB. The `alpine:3.7` image is about 4MB. edit I misunderstood the parent, they meant to use `golang:1.10-alpine` as the build image, not the run image, as in: FROM golang:1.10-alpine COPY . /go/src/bitbucket.code.company-name.com.au/scm/code…
Re: How to start a Go project in 2018
#29Has 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.
Re: How to start a Go project in 2018
#30Earlier quoted context omitted.
> As a Python developer, I am no stranger to slightly ridiculous packaging / environment woes. Speaking of which, what is the best way to start a python project in 2018, now? Python's version and dependency management is my least favorite aspect of the language.
It's still a bit new, but I think pipenv [1] is the new standard now. No need to directly work with pip or virtualenv anymore, and the equivalent requirements file works more like npm/yarn. [1] https://github.com/pypa/pipenv