1. 8

  2. 9

    I feel that a discussion of Go code management in October 2018 that does not mention go mod and instead spends time on vendor/ is not doing a reader any favors.

    Outside of that issue, this article is well-written, plainspoken, and easy to read.

    1. 4

      Thanks for the kind words! I didn’t touch on go mod because some of its interfaces (e.g. go list -m’s output and how go mod interacts with vendor) are not yet stable, so the dependency analysis situation is a bit up in the air. In my practical experience, go mod adoption has been fairly slow.

      go mod solves most (all(?)) of the problems with vendor, by (1) disallowing the nested vendor situation and (2) forcing packages in different repositories to have explicit versioning information when imported.

      My takeaway from this feedback is to at least mention the existence of newer approaches to avoid misleading readers, even if it’s not completely clear how they fit in yet.

      1. 3

        I too am utterly confused as to why the article doesn’t seem to mention go mod at all, and can’t see how the article can be useful to a Go programmer in this situation. Also, when I realized that, I stopped reading the text and only skimmed the rest trying to quickly confirm if I’m maybe wrong, but this didn’t seem to be the case. I don’t understand it especially because go mod has a potential to solve at least some problems described in the article (can’t say if all as I didn’t read it all, as I explained above).

        1. 1

          I only lasted until “It gets a lot of things right: great tooling, a pragmatic language design, and a sane module system.” … are there any useful insights after that?

          1. 2

            Thanks for the feedback! This was written as an explanation of various pitfalls in Go dependency analysis. I think my takeaway from the feedback above is to provide more actionable information.

            1. 2

              Don’t take it too seriously, it sounded harsher than I intended.

              1. 1

                Personally (apart from adding info about go mod), I’d also suggest maybe trying to add some simple example to help explain what you’re trying to demonstrate/communicate. As of now, I’m personally really confused and can’t wrap my head around as to what does the article actually try to tell me. You’re starting the article with “pathologies”, which is a very strong word (at least to me); then you’re saying a lot of “Go does X well/ok/right” — which is confusing to me when you claim to be describing pathologies; then you describe a few ways to describe dependencies in Go projects; still no hint of “pathologies”, and it actually feels to me that you’re using them rather to advertise some options of your product, instead of focusing on the premise of the article; then you seem to describe some subtle situations (presumably those are the claimed “pathologies”?), without providing examples (only claiming “some projects” — that is, what projects exactly? see e.g. Wikipedia’s “who?” template), which currently makes them super hard to understand for me.