doc: do not refer to "lazy module loading"

[rsc]

I think we agreed to call the new module logic something like "fast module loading" or "reduced module graphs" instead of "lazy module loading". The problem with "lazy module loading" is it will mean approximately nothing to anyone.

We need to fix the docs - at least /doc/go1.17 but maybe other places - before the actual release.

/cc @bcmills @jayconrod

[myitcv]

Would an alternative to trying to give this feature a descriptive name be to simply call it "module loader v2"? Then defer to documentation for what that actually means, differences vs the original loader.

[rsc]

I'm leaning toward "precise module loading" here and "Go 1.17 precise module loading" elsewhere.
But @bcmills is out today so let's wait until he's back. I'm sure he'll have something appropriate.

[jayconrod]

@bcmills split this into a few different concepts in https://golang.org/cl/333629. "Module graph pruning" is one, but "lazy loading" is still there.

Would be good to chat about this more when he gets back. I think "lazy" is a good word here to explain "not loaded until we need it". But we need to explain a lot more than that.

[cameracker]

It may be worth mentioning that "Lazy loading" has some precedence in other languages (React and Angular come to mind, though the user overlap there might be low 😆 )

"Module graph pruning" sounds like "tree shaking" to me. Whatever name you folks choose, I'd suggest using something standard from other package managers so users understand what they're operating with.

[peterbourgon]

The problem with "lazy module loading" is it will mean approximately nothing to anyone.

Data point of one: "lazy" is a reasonably well-understood way to describe deferring something, often a calculation, until it's needed. I haven't personally seen anyone confused by its implications w.r.t. module loading.

[andig]

Without following the discussion it is not even sufficiently clear if the terminology refers to the go toolchain or to any runtime behaviour.

[bcmills]

My current thinking is that the implementation really spans three concepts:

• “Module graph redundancy” is the new invariant that we maintain for go.mod files that specify Go 1.17 and up. It adds redundant entries in each go.mod file that allow us to reconstruct relevant facts about more-distant parts of the module graph.

• “Module graph pruning” is the way that we use the local redundancy in direct dependencies' go.mod files to reduce the overall size of a module's requirement graph. It is based on the observation that the information about the module graph that is not preserved redundantly in a given module's go.mod file is not relevant to the packages in that module.

• “Lazy module loading” is the way that we use use the local redundancy in the main module's go.mod file to reduce the need to download and read the go.mod files that remain in the graph after pruning. It will likely have a smaller long-term impact than graph pruning, but it may still be useful for some projects — and it was the concept that led us to graph redundancy in the first place, so it is how we have framed the discussions around graph redundancy in the past.

[bcmills]

I'm happy to rename any of those three concepts, but I'm probably too close to the implementations to come up with better names for them.

I guess “lazy module loading” could be “speculative package loading”, maybe? “Lazy loading” is when we proceed to loading packages under the assumption that the go.mod file is complete and consistent, and only do the work to check its consistency if we see evidence that that assumption is wrong (like an import of a missing package, or a go.mod file for a loaded package that actively contradicts some version recorded in the main module's go.mod file). But I don't really have a better word than “lazy” for “avoiding work based on optimistic assumptions”. 😅

[rsc]

Discussed with team.
Converged on "Go 1.17 pruned module graphs" to describe the fundamental new feature here.
What go mod tidy -go=1.17 does is convert to "Go 1.17 expanded go.mod files"

[gopherbot]

Change https://golang.org/cl/339991 mentions this issue: _content/ref/mod: update terminology for Go 1.17 changes

[gopherbot]

Change https://golang.org/cl/335135 mentions this issue: doc/go1.17: clarify lazy-loading changes

[gopherbot]

Change https://golang.org/cl/345393 mentions this issue: cmd/go/internal/modload: use "pruned" instead of "lazy" to describe pruned module graphs