Go Modules in 2019

One of the thing that&#x27;s always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it&#x27;s me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wrong.<p>It&#x27;s kind of satisfying to see that the &quot;Go way&quot; wasn&#x27;t the best way after all and that some of these things are actively being addressed. I hope it makes the community a bit more welcoming as well.

I really want to get into Go, I like that it&#x27;s opinionated, I like that it&#x27;s compiled, I like that it&#x27;s garbage-collected, I like that coroutines are built-in.<p>My primary use case is scientific computing, both data processing and interactive visualization.<p>I know Julia is an option as well.<p>For reasons I don&#x27;t want to bother getting into I dislike Python.<p>Thoughts?

Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with &quot;npx&quot;; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn&#x27;t compile.)<p>I am glad to see that the go team is working on cleaning up the tooling situation. I used gocode, then started using modules, found that the primary version was unmaintained, and had to switch to a different fork. I believe I also needed a different version of goimports for a while. Having all this tooling unified into the langserver maintained alongside go sounds wonderful. I hope other languages do the same thing.

Maybe it&#x27;s just me but I hate this option. Are we really, really trying to optimize the downloading of source code ? All 5 megabytes of it ? Why would you do that ?<p>I regularly find myself in a position that this system would make impossible: I need a few custom changes in public available libraries. An extra method. A bugfix. What have you. This makes that impossible using the default method.<p>What we want is consistent builds. That means a build that happens, with the same source, with the same ... every time, always, on everybody&#x27;s workstation.

Nice overview, however a small correction to the statement about Maven repositories.<p>Decentralized support has been a thing since the last decade.

&gt; One of the most important parts of the original design for go get was that it was decentralized<p>That&#x27;s one of the things I like in go most. Having decentralized packages via domains and URLs and then index them (godoc.org works very well), it mirrors the design of the Web. In contrast npm, Rust and others that are tightly coupled to one site feels like Google AMP - centralizing and hosting everything in one place.

It seems like there&#x27;s a mistake in the diagram. The &quot;notary → mirror&quot; arrow should be replaced with a &quot;notary → go command&quot; one, because the go command shouldn&#x27;t trust the mirror when it comes to cryptographic hashes.

A centralized module index will be nice, i tend to end up searching github.com which leaves out all the other sites or locations that could have a module that solves my problem.

So the mirror will serve both the package and signed hashes, what if the package has been indexed in the central index but not yet signed by the notary?

It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. Since it was obvious from day 1 to most people from other ecosystems maybe they shouldn&#x27;t have so much NIH. We&#x27;ll likely get exceptions and generics soon as well. What a waste of time.