/cc @dmitshur

Issue #43430 is related. CC @jayconrod.

Based on the discussion there, I suspect we prefer suggesting go get over go mod tidy for the specific task of adding new dependencies. (go mod tidy is fine to use for other module management, like removing unused dependencies.)

I think at tip we recommend go get instead of go mod tidy. In any case, the text will need to be updated.

I'll take a look soon after 1.16 release blockers are resolved.

I just noticed that starting in Go 1.16, go run . doesn't work without a module, too.

https://golang.org/cl/283635 replaced go run hello.go with go run ., so that part will break with Go 1.16 too. My suggestion would be to introduce a go mod init earlier, because I think modules is something every developer will encounter in the first hour, while the command-line-arguments package is not something they need to know about at all, and can only confuse them. Alternatively, the CL can be rolled back.

Change https://golang.org/cl/288277 mentions this issue: content: improve getting started document

go mod tidy is easier to use, but go get is more precise. Since this doc is targeted at new users, go mod tidy is probably a better choice. Either is fine though.

I've heard the two commands suggested interchangeably at times. I think we should decide what the contexts for recommending go get and go mod tidy are and stick with them in docs.

This is clearly a new user hunk of documentation. If go mod tidy is best for context, then we should keep it here. However, being the easiest doesn't necessarily make it the best practice (though the easiest should be the best practice for new users, IMO). We also should be about introducing the best practice commands for a given workflow.