This is certainly a duplicate of the rejected #51967 – but some months have passed and people have been using go.work in real life projects.

One of the great thing about Go's build tools is that you in most cases can do a go install in a random Go project and get a fully working executable.

With GOWORK=on as a default, that is no longer the case:

• If you have a go.work file committed to CVS, then that file will be used for module resolution.
• If you have that file in .gitignore then you will get a different build compared to some other person who clones and builds your project.

I see arguments in #51967 that you should really control this with Make scripts and similar, which is an argument I find odd. The production build is where the defaults should be directed and, again, one beauty of Go's build tools is the simplicity of just doing go install.

A related issue #53502 is discussing whether go.work should be committed to CVS or not, a question that might have been possible to answer if GOWORK=off was the default.

The final argument in the #51967 thread was:

Given that there are no new footguns here, just the same ones we had in replace directives ...

The big difference here is that the foot gun now is invisible.

With replace directives we had a well defined situation of "development replace directives should be temporary and never be committed to CVS". It took some care to live by that, and I have certainly shot myself in the foot more than once, but the current situation is that I have to either 1) Not use go.work files or 2) Create Make files for all of my projects (or some other tool to set GOWORK=off), which I would need to remember to use myself and document so others also remembers not to just do the simple go install.

The ideal situation would be to be able to turn on GOWORK when I'm doing development, e.g. GOWORK=on code .