1. 48

  2. 16

    I’m ambivalent on this post. On the one hand, I think it’s completely fair to say the Go team could/should do more to communicate how modules are supposed to work, especially if there’s widespread confusion. I don’t know if that confusion is widespread, but let’s be generous and assume it is. Adding warnings to Go’s tooling seems like a good suggestion, although I have some questions.

    On the other hand, the rest of this boils down to not liking the solution because it doesn’t work the way the author wants it to. It’s widely known that the Go team is very opinionated, and I’m honestly a bit tired of reading this sort of sniping.

    The closing paragraph also seems very poorly thought out. How does the optional versioning approach described work in practice? How do I as a module author indicate that I’m using (or not using) the standard versioning approach? How does that choice impact module consumers? The “best” option leaves so many unanswered questions that it’s not clear to me it’s a realistic option at all.

    So yeah, a frustratingly mixed read.

    1. 23

      It’s widely known that the Go team is very opinionated, and I’m honestly a bit tired of reading this sort of sniping.

      The problem seems to be that, increasingly, the Go team’s opinions aren’t working for people who actually use Go outside of Google. It’s not “sniping” to articulate why those opinions aren’t working and suggest alternatives.

      1. 9

        It’s sniping because, as I say above, beyond mere suggestion the author doesn’t wrestle at all with how his suggestions would actually work in practice. It’s sniping because it’s easy.

        1. 16

          So you’re upset they took the easy route of dismissing an opinionated stance that didn’t work for them.

          But to do so, you’re… taking the easy route of dismissing an opinionated stance that wouldn’t work for you.

          Again, it’s OK for people not to like something the Go team did. It’s not automatically “sniping” or whatever other derogatory term.

          1. 6

            Cute wordplay aside, if you’re going to do something unidiomatic, then the burden of proof is on you to show that it’s an improvement. Otherwise I’m in my right not to take this seriously.

            1. 16

              I think the author’s point is that most people are not aware that not only what they are doing is considered “unidiomatic” by the team, but also that the “idiomatic” approach is not something they want to adopt.

      2. 3

        I wish the author separated the criticism of SIV from the old tired vgo/dep drama. I find that stuff tiring as well. I’ve been enthusiastic about modules from day 1 (after much suffering from godep, glide, and dep) however, overtime started to think that SIV probably wasn’t worth it compared to just telling people to rename on breaking changes. I’m sure had they gone without SIV that that choice would have garnered lots of cheap criticism too.

      3. 28

        Google spends years insisting something isn’t a problem, because it’s not a problem for their workflow, and finally tries to solve it without consulting the people who care about it and make dumb design decisions. News at 11.

        1. 17

          Oh wow, and just when I thought the go dependency mess couldn’t possible have gotten worse than ca ~2016…

          1. 11

            What on earth are they up to? I think this started with GOPATH, a bizarre fixed path that other languages are quite alright without. It’s just descended into an increasing mess since. There are some people with half a century plus of experience, yet this seeming aimlessness - what are they trying to achieve?

            1. 3

              what do you mean by a fixed path? don’t all languages need a location for their libraries?

              1. 6

                Source code had to live in a particular path too. It shouldn’t be required now, but I recently had a cryptic code generation issue magically solved when I moved my code to ~/go/src/github.com/name/name.

          2. 5

            It’s important to keep in perspective that the backwards incompatibility issue with non-module builds that was patched into older releases was done so all the way back into the Go 1.9 release branch. Go 1.9 was originally released in August of 2017. I don’t know of anyone that is still using a Go release from back then, which is mostly a product of how well the Go team prioritizes not introducing breaking changes. The Go team also only provides security patches for the latest two version branches of Go (currently, 1.14 and 1.15), so nobody should be using a release that old regardless.

            1. 2

              It was painful from the developer perspective because your dependencies and deps-of-deps might have not had module support, and might already be a v2/v3 etc. (thus blocked you from sanely supporting non-module and module at the transition period)

              1. 4

                There was never a need for your dependencies, or their dependencies, to be or understand modules in order to consume them in a module build. They just worked. The only module “feature” that wouldn’t have been possible with this code is the inability to contain multiple major versions of a package, since that does rely on semantic import versioning (what this author is challenging).

            2. 8

              Go modules having the v2 chilling effect is why I’ve started using Rust in my personal projects.

              1. 4

                I really don’t understand why people can’t just name their package like sqlite. Instead of:


                Why did they not opt for just:


                It seems to me this way would work without any special tools.

                1. 3

                  I agree with you, but it is Go modules’ position that treating different major versions of an artifact as completely different artifacts is so important that it should be mandatory for all artifacts in the ecosystem.

                  1. 1

                    If I’m understanding you correctly, that more sense - Thanks for explaining.

                  2. 1

                    I agree strongly with this. I think overall, the SIV (semantic import versioning) rule creates more work and problems then it solves. Simply renaming your package on breaking changes I think works out better overall though I understand the rational of SIV.

                  3. 4

                    It’s interesting to me since it doesn’t seem that they have a “v2+ problem” but probably more of a messaging problem.

                    You are on your own to piece together how SIV works via the myriad of blog posts, wiki pages, and Github issues. The information being spread all over the place doesn’t help anyone get comfortable with the concepts. I’ve gone so far as to write an internal wiki for all go teams in my org that is simplified and answers most questions about modules plainly.

                    The other part of the “messaging” problem was the journey just to get to modules. Google and the go team let the “community will sort out dependencies” experiment go on for way too long. They compounded this with the fact that we went from a “blessed” solution in dep to what I’ll call a paradigm shift with modules.

                    So, some mistakes to learn from and areas for investment but nothing that is absolutely a deal break (at least to me).

                    As an aside, we are working on some proposals to help with deprecation / alerting to newer major versions. Would love any comments or feedback!

                    1. 3

                      I just deleted all my v2.* tags and go on with v1.2.* tags.

                      1. 7

                        So either you’ve made breaking changes to you API, and now you’re violating Semantic Versioning, or did didn’t and you never should have gone to v2.x anyway.

                        1. 26

                          I broke semver. https://xkcd.com/1172/