<story><title>How to start a Go project in 2018</title><url>https://boyter.org/posts/how-to-start-go-project-2018/</url></story><parent_chain></parent_chain><comment><author>zimbatm</author><text>It&amp;#x27;s distasteful of Go to impose a filesystem layout.&lt;p&gt;Any other language that I work with understands that dependencies should be self-contained within the project folder. Each project has it&amp;#x27;s own set of dependencies that have been tested to work together. The user can select where to checkout the project, or even have multiple copies of the same project lying around.&lt;p&gt;To achieve the same thing with Go, one has to set a different GOPATH per project, and then checkout the project deep into that root. This is not convenient as a developer and as a software packager. Or give in and having to resolve dependencies that work with all the current projects. Given that Go doesn&amp;#x27;t really do package versioning, finding the right set of commits that all work together is a exponential nightmare.&lt;p&gt;Now that since Go 1.6 each project can have its own vendor&amp;#x2F; folder, GOPATH shouldn&amp;#x27;t be required. I should be able to checkout the project where I want and then have the tools look into the vendor&amp;#x2F; folder to resolve any dependencies. Please change it that way. The reason govendor and all these tools are complicated is because of this GOPATH madness. Synching dependencies between GOPATH and vendor&amp;#x2F; should only be a problem for Google, not the rest of us.</text></comment>
<story><title>How to start a Go project in 2018</title><url>https://boyter.org/posts/how-to-start-go-project-2018/</url></story><parent_chain></parent_chain><comment><author>aodin</author><text>If you&amp;#x27;re using Go with Docker 17.05 or higher, I recommend a multi-stage Docker build. Official documentation here: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.docker.com&amp;#x2F;develop&amp;#x2F;develop-images&amp;#x2F;multistage-build&amp;#x2F;#use-multi-stage-builds&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.docker.com&amp;#x2F;develop&amp;#x2F;develop-images&amp;#x2F;multistage-bu...&lt;/a&gt;&lt;p&gt;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&amp;#x27;ve seen images sizes reduced by over 95%.&lt;p&gt;Revising the example in the article:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    FROM golang:1.10
    COPY . &amp;#x2F;go&amp;#x2F;src&amp;#x2F;bitbucket.code.company-name.com.au&amp;#x2F;scm&amp;#x2F;code
    WORKDIR &amp;#x2F;go&amp;#x2F;src&amp;#x2F;bitbucket.code.company-name.com.au&amp;#x2F;scm&amp;#x2F;code&amp;#x2F;
    RUN CGO_ENABLED=0 go build main.go

    FROM alpine:3.7
    RUN apk add --no-cache ca-certificates
    COPY --from=0 &amp;#x2F;go&amp;#x2F;src&amp;#x2F;bitbucket.code.company-name.com.au&amp;#x2F;scm&amp;#x2F;code&amp;#x2F;main .
    CMD [&amp;quot;.&amp;#x2F;main&amp;quot;]
&lt;/code&gt;&lt;/pre&gt;
The `CGO_ENABLED=0` and `apk` are oddities of Alpine Linux specifically. The image you choose to run your binary may not need these.</text></comment>