I slipped briefly into Major Grumpiness when I read that. It’s highly disingenuous.
Module support in the go command is now ready for production use.
So why has the entire Go programming community (outside Google, are they using this stuff yet or still on their internal build systems) spent the last year plus dealing with fallout from Go Modules, migrating over to it, deciding how to deal with other build systems, working around bugs, and more?
That’s not a sign that something was deployed as “not fit for production use yet”.
Go 1.13 cut over to Go modules as on by default. Because it wasn’t yet fit for production use?
One small sentence inspiring such utter frustration.
I use it happily in my own projects, but had to report a few bugs in the proxy stuff. $employer hit major pains just before I arrived and had to use the env var to disable modules to be able to keep doing line-of-business work.
Citation: no. Just go look at everyone who was on dep just before the vgo announcement; or the problems hit when people kept running into Go modules not updating to a “needless” new version which was a security fix, because unlike every other mainstream dependency management system an unpinned version didn’t get the latest stable release but the earliest release which met all constraints.
The first part about bugs you found and reported, and $employer pains is very informative and valuable, thanks for sharing it.
As to the second part, it’s FUD I vehemently disagree with. First of all, please don’t claim “everyone” in your arguments and use “just this and that” rhetoric tricks. I mostly managed to avoid dep for all its lifetime, and I actually expected problems with it from onset. One time I couldn’t avoid it, was when I tried using dep once to install some big package which used it. In that case I had abysmal experience with it: the project never managed to finish downloading, dying somewhere in the network of dependencies after several minutes. As to the community drama with switching from dep to vgo, please don’t beat the dead horse; feathers were ruffled, lessons were (hopefully) learnt, it was basically a community mismanagement issue, not a technical one. As to “people running into Go modules not updating to new version”, again, citation needed. You can agree or disagree with this design choice (I personally do agree), but using it as argument for modules being “not fit for production use yet” is disingenuous.
I’m in the happy camp too. Maybe, because I jumped into the Go universe at a time when moving to modules was already set in stone. I’ve used modules for all of my personal projects so far, without any noticeable issues.
Even with a few warts, it was a massive improvement, and worth adopting.
There wasn’t really very much in the way of fallout, mostly just a few third-party tools that needed to catch up, and one edge-case that was discovered in the module hasher. Nothing major in the design or in the implementation of modules in Go itself changed between 1.11 and 1.14; this is just sane release engineering. It’s working well, so now there’s a note that says “go ahead and use it, if you were waiting!”
Is gorename a third-party tool? This is an earnest question, I’m not sure if its inclusion in the tools repo means anything one way or the other. If it is a first-party tool, I think it’s pretty unacceptable that a feature released with “beta” status didn’t even have 100% support in the first-party tooling landscape for a good while, and if it isn’t, it was still quite frustrating to be dealing with a language ecosystem where the main language version has a 1 in the major version slot and a number higher than 10 in the minor version slot and having to choose between either having a basic automated refactoring feature or having a tolerable dependency management system.
It’s kind of “second-party”. golang.org/x is stuff that’s official, but at the same time, officially not included under compatibility guarantees or tied to the language release cycle.
are they using this stuff yet or still on their internal build systems
Google uses the internal version of Bazel (with a different way of using it than rules_go: no go_default_library, etc). It’s unlikely they will use modules for the main codebase…. ever (at least IMHO).
I slipped briefly into Major Grumpiness when I read that. It’s highly disingenuous.
So why has the entire Go programming community (outside Google, are they using this stuff yet or still on their internal build systems) spent the last year plus dealing with fallout from Go Modules, migrating over to it, deciding how to deal with other build systems, working around bugs, and more?
That’s not a sign that something was deployed as “not fit for production use yet”. Go 1.13 cut over to Go modules as on by default. Because it wasn’t yet fit for production use?
One small sentence inspiring such utter frustration.
Citation needed. I’ve been using Go modules quite happily for months.
I use it happily in my own projects, but had to report a few bugs in the proxy stuff. $employer hit major pains just before I arrived and had to use the env var to disable modules to be able to keep doing line-of-business work.
Citation: no. Just go look at everyone who was on
depjust before the vgo announcement; or the problems hit when people kept running into Go modules not updating to a “needless” new version which was a security fix, because unlike every other mainstream dependency management system an unpinned version didn’t get the latest stable release but the earliest release which met all constraints.The first part about bugs you found and reported, and $employer pains is very informative and valuable, thanks for sharing it.
As to the second part, it’s FUD I vehemently disagree with. First of all, please don’t claim “everyone” in your arguments and use “just this and that” rhetoric tricks. I mostly managed to avoid
depfor all its lifetime, and I actually expected problems with it from onset. One time I couldn’t avoid it, was when I tried usingdeponce to install some big package which used it. In that case I had abysmal experience with it: the project never managed to finish downloading, dying somewhere in the network of dependencies after several minutes. As to the community drama with switching fromdeptovgo, please don’t beat the dead horse; feathers were ruffled, lessons were (hopefully) learnt, it was basically a community mismanagement issue, not a technical one. As to “people running into Go modules not updating to new version”, again, citation needed. You can agree or disagree with this design choice (I personally do agree), but using it as argument for modules being “not fit for production use yet” is disingenuous.I had a lot of pain with switching to Go modules with a pile of Kubernetes dependencies. Here’s someone else complaining about it.
I’m in the happy camp too. Maybe, because I jumped into the Go universe at a time when moving to modules was already set in stone. I’ve used modules for all of my personal projects so far, without any noticeable issues.
Is gorename a third-party tool? This is an earnest question, I’m not sure if its inclusion in the tools repo means anything one way or the other. If it is a first-party tool, I think it’s pretty unacceptable that a feature released with “beta” status didn’t even have 100% support in the first-party tooling landscape for a good while, and if it isn’t, it was still quite frustrating to be dealing with a language ecosystem where the main language version has a 1 in the major version slot and a number higher than 10 in the minor version slot and having to choose between either having a basic automated refactoring feature or having a tolerable dependency management system.
It’s kind of “second-party”.
golang.org/xis stuff that’s official, but at the same time, officially not included under compatibility guarantees or tied to the language release cycle.Google uses the internal version of Bazel (with a different way of using it than rules_go: no go_default_library, etc). It’s unlikely they will use modules for the main codebase…. ever (at least IMHO).