| THere is a subtle but significant difference between the approaches of Deno and Go. Deno directly use standard URIs to import packages. Go imports syntactically appear as schemeless paths, which boils down to the semantics of importing URIs from an implicit private go:// scheme. And that catches two fishes at once: 1) the go:// namespace is isomorphic to the https:// namespace, so the default resolution strategy is just to pipe through this isomorphism. This is convenient, makes sense right away and avoids the a priori need of a central registry. 2) Whenever it's needed, the resolution can be instructed to do some custom thing instead of casting to https://. The exemplar instance of 2) is the usage of sibling packages. They wanted to make it possible to have several packages within a single module, whereby the module serves as a compilation unit. So when an import path is a subpath of the module path, then the package is looked up locally, relative from the root of the current module. There is no way you could get away with such a bending of a https:// URI. But go:// being a private scheme gives the freedom to proceed so. (The go:// scheme is just my own literary device, but this semantics is explained clearly in simple terms at https://golang.org/doc/code.html.) |