<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>kitd</author><text>It looks complicated because OP is describing the situations both before and after the introduction of go mod.&lt;p&gt;Just use &lt;i&gt;go get&lt;/i&gt; to get initially, and &lt;i&gt;go mod&lt;/i&gt; to organize thereafter. It is very simple and occupies &amp;lt;1% of my cognitive effort writing go code.</text><parent_chain><item><author>na85</author><text>Ugh, reading this reminded me why I felt good moving away from Go after the honeymoon period was over.&lt;p&gt;Actually writing the code was fun at first, but everything else around the actual act of composing code was thoroughly awful UX.</text></item><item><author>mkdirp</author><text>I can shed some light on some of your questions for you.&lt;p&gt;&amp;gt; most of the documentation talks of gopath&lt;p&gt;Historically go used a GOPATH env var. Go code had to live under there under `$GOPATH&amp;#x2F;src&amp;#x2F;&amp;lt;module-path&amp;gt;`. When doing an import, go would look at the import path, and find it in GOPATH. This wasn&amp;#x27;t flexible enough but still exists under the hood as it&amp;#x27;s where go saves (caches?) packages globally. If you have a go.mod&amp;#x2F;go.sum file in your project, in general, you won&amp;#x27;t have to worry about GOPATH.&lt;p&gt;Worth noting that go, while widely used, was created to solve Google&amp;#x27;s problems (I guess at least initially?), where (from my understanding) they have a huge monorepo. At that point, having everything live under such a GOPATH somewhat makes sense.&lt;p&gt;&amp;gt; why are go mod vendor and go mod tidy different commands?&lt;p&gt;Go mod vendor puts all the dependencies in a .&amp;#x2F;vendor directory. Often used to commit your packages directly into git. There might be other advantages, not sure, but personally I don&amp;#x27;t use it. Go is able to pick up the packages in your go.mod directly from $GOPATH.&lt;p&gt;Go mod tidy ensures your go.mod matches your used package. E.g. if you remove usage of a package in your code, go mod tidy is able to pick that up. In addition, it also ensures your go.sum matches go.mod.&lt;p&gt;&amp;gt; the lack of “one true way” is very strange. some projects module. some projects check in dependent source code&lt;p&gt;This is a historic issue. Prior to 1.12 (I think), go modules didn&amp;#x27;t exist, and there were different community projects that attempted to solve go package management.&lt;p&gt;&amp;gt; do i download with go get? or go install? or go get -u?&lt;p&gt;Again, historic issues, iirc go get -u forces an update of a package, meaning this updates your go.mod file. Go get without -u does not force update the package. It update your go.mod file if you haven&amp;#x27;t included the module previously. Go install is used for go main packages. It fetches the code, builds it (so it must be a main package), and puts the final binary in $GOPATH&amp;#x2F;bin. Assuming you have that in your patch, you can use it straight away.</text></item><item><author>foolfoolz</author><text>go modules is one of the hardest things about learning go as a new learner. most of the documentation talks of gopath. the go mod error messages are extremely cryptic. why are go mod vendor and go mod tidy different commands?&lt;p&gt;the lack of “one true way” is very strange. some projects module. some projects check in dependent source code. some projects have a version number in the package name. do i download with go get? or go install? or go get -u?&lt;p&gt;i can’t think of another build system that has so much variation just in declaring and importing dependencies</text></item></parent_chain></comment><story><title>Go mod’s lesser known features</title><url>https://verdverm.com/go-mods/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>littleroot</author><text>I&amp;#x27;m the opposite: I&amp;#x27;m writing Go for a living and I hate everything about the language itself, but I found the de-facto toolchain ok-ish and probably the least obtrusive thing about the whole thing.&lt;p&gt;Imho, many languages would massively benefit with the kind of tooling Go has out of the box. I heard Rust&amp;#x27;s tooling has some great stuff too and it&amp;#x27;s in my immediate plan to learn some Rust.</text><parent_chain><item><author>na85</author><text>Ugh, reading this reminded me why I felt good moving away from Go after the honeymoon period was over.&lt;p&gt;Actually writing the code was fun at first, but everything else around the actual act of composing code was thoroughly awful UX.</text></item><item><author>mkdirp</author><text>I can shed some light on some of your questions for you.&lt;p&gt;&amp;gt; most of the documentation talks of gopath&lt;p&gt;Historically go used a GOPATH env var. Go code had to live under there under `$GOPATH&amp;#x2F;src&amp;#x2F;&amp;lt;module-path&amp;gt;`. When doing an import, go would look at the import path, and find it in GOPATH. This wasn&amp;#x27;t flexible enough but still exists under the hood as it&amp;#x27;s where go saves (caches?) packages globally. If you have a go.mod&amp;#x2F;go.sum file in your project, in general, you won&amp;#x27;t have to worry about GOPATH.&lt;p&gt;Worth noting that go, while widely used, was created to solve Google&amp;#x27;s problems (I guess at least initially?), where (from my understanding) they have a huge monorepo. At that point, having everything live under such a GOPATH somewhat makes sense.&lt;p&gt;&amp;gt; why are go mod vendor and go mod tidy different commands?&lt;p&gt;Go mod vendor puts all the dependencies in a .&amp;#x2F;vendor directory. Often used to commit your packages directly into git. There might be other advantages, not sure, but personally I don&amp;#x27;t use it. Go is able to pick up the packages in your go.mod directly from $GOPATH.&lt;p&gt;Go mod tidy ensures your go.mod matches your used package. E.g. if you remove usage of a package in your code, go mod tidy is able to pick that up. In addition, it also ensures your go.sum matches go.mod.&lt;p&gt;&amp;gt; the lack of “one true way” is very strange. some projects module. some projects check in dependent source code&lt;p&gt;This is a historic issue. Prior to 1.12 (I think), go modules didn&amp;#x27;t exist, and there were different community projects that attempted to solve go package management.&lt;p&gt;&amp;gt; do i download with go get? or go install? or go get -u?&lt;p&gt;Again, historic issues, iirc go get -u forces an update of a package, meaning this updates your go.mod file. Go get without -u does not force update the package. It update your go.mod file if you haven&amp;#x27;t included the module previously. Go install is used for go main packages. It fetches the code, builds it (so it must be a main package), and puts the final binary in $GOPATH&amp;#x2F;bin. Assuming you have that in your patch, you can use it straight away.</text></item><item><author>foolfoolz</author><text>go modules is one of the hardest things about learning go as a new learner. most of the documentation talks of gopath. the go mod error messages are extremely cryptic. why are go mod vendor and go mod tidy different commands?&lt;p&gt;the lack of “one true way” is very strange. some projects module. some projects check in dependent source code. some projects have a version number in the package name. do i download with go get? or go install? or go get -u?&lt;p&gt;i can’t think of another build system that has so much variation just in declaring and importing dependencies</text></item></parent_chain></comment><story><title>Go mod’s lesser known features</title><url>https://verdverm.com/go-mods/</url></story>