Go: proposal: cmd/go: rename go mod init to go init

[leighmcculloch]

What version of Go are you using (go version)?

go version devel +65fa2b615b

Proposal

In the latest version of go mod that's available on tip, go mod -init has become go mod init. I propose that the concept of initializing a module be so core to developing in go, and something so core and critical to developing a new package, that it should be only go init.

Why

One of the goals that has been expressed for versioning in Go, is for it to be a part of using the go tool without needing to learn an extra tool. For general day-to-day development the engineer shouldn't need to research up on what go mod, vgo, or modules are. When I write new Go code I want to initialize my folder so it has what I need to get going with a new package. Ideally running something like go init does that, without me needing to learn what the concept of mod is, until such time as it's relevant to me.

[agnivade]

Have you seen @bcmills' answer - https://github.com/golang/go/issues/26581#issuecomment-408998757 ?

[leighmcculloch]

@agnivade I had not but I've read that thread now. I don't think any of the other sub-sub-commands necessarily need moving. They'd be nice to move, especially go vendor, but I think day-to-day because engineers will encounter go init upfront, removing the word mod will reduce the concepts and knowledge required to get going, which is huge for engineers new to Go.

@rajender made the same suggestion in https://github.com/golang/go/issues/26581#issuecomment-408721729 as I am here, rename go mod init to go init.

[kardianos]

Once developing Go outside of GOPATH becomes common for new projects, I think it much more likely that they will just write out "module path/name" in go.mod.

[thepudds]

@gopherbot, please add label modules

[rsc]

When I write new Go code I want to initialize my folder so it has what I need to get going with a new package. Ideally running something like go init does that, without me needing to learn what the concept of mod is, until such time as it's relevant to me.

In general the go subcommands operate on packages. The go mod command groups a bunch that operate on the current module instead. I would expect go init to initialize one package, not a module. And in fact your comment suggests that you expect the same thing. But that's _not_ what go mod init does, and in fact there is no need for any per-package initialization. So while I appreciate the idea that go mod init be elevated to go init, I think that would blur the lines in an unproductive way. It's actually important to understand the distinction between a module (a group of packages) and a single package. It's arguably harmful to hide that.

I realize that there is cargo init, npm init and so on. But I don't think that being like other systems justifies introducing confusion about modules versus packages.

[rsc]

Going to close this issue for now. It does seem to me that as we come to understand modules better over the next few releases, we may decide they are so central to the use of the go command to merit elevation to 'go init'. But the moment it would at least be premature.