4 ms·

Odd that the article doesn’t mention Go. Deno works like Go. It’s slightly different in that Go added a system for version rewrites recently (“modules”), but ot

Odd that the article doesn’t mention Go. Deno works like Go. It’s slightly different in that Go added a system for version rewrites recently (“modules”), but other than that it’s the same, and if importmaps ever happen, it will be the exact same. Also Deno has a command line fallback for its version of GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. But other than cosmetic differences, it’s pretty much identical to Go.

maxmcd 6y ago
I've been skimming the arguments so I might have missed something big, but isn't the key distinction that Deno can take anything from a URL? Go's "go get" is backed by version control systems, but you could freely point your deno at "http://dangerous.com/evil.ts" http://dangerous.com/evil.ts". I thought the concern was about the potentially problematic flexibility.
- earthboundkid 6y ago
  Go has a system for telling where to fetch based on the URL response. You can basically send anything if you are evil, but Go modules keep a hash of seen content (what Deno calls a lockfile), so you’d notice that it changed.
- 14u2c 6y ago
  Isn't that the advantage though, that you can do exactly that without concern. > deno run --allow-write=~/only-evil-here http://dangerous.com/evil.ts http://dangerous.com/evil.ts
parhamn 6y ago
> GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. This gave me a laugh but it’s not fair! I’d guess most of the GOPATH outcry was the annoyance around managing automated and other non-dev environments.
- Groxx 6y ago
  Also at having to put your source in the gopath at its import path. So you couldn't have 'project/' and 'project2/', you had to have 'gopath1/src/path/to/project/' and 'gopath2/src/path/to/project2' or you had absolutely no isolation between things (until vendor (and that leaks (and it still requires that deep folder structure in some cases (and it took them quite a while to accept it in core tools)))). GOPATH was nothing short of a monstrosity. Its problems were truly obvious on day 1, but it lingered and infected everything.
  - earthboundkid 6y ago
    I don’t agree that it was a monstrosity. I do agree that developers didn’t like having to include “extra” folders. I think even just making a GOSRC var and dropping /src would have bought good will. (Go has a GOBIN.)
  - jrs95 6y ago
    I still use this directory structure and it doesn't really bother me honestly. Makes it very easy to work with multiple local repositories without having to worry about any linking or installing bullshit you have to do with other systems.
    - parhamn 6y ago
      It is certainly remarkable how long this is effective for in Golang. Libs just don't break.
  - xrd 6y ago
    Are you sure you aren't discussing lisp here? :)
searchableguy 6y ago
Importmaps are available in deno behind an unstable flag. A few npm clones are using them.
dzsekijo 6y ago
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:// 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:// 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:// 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. https://golang.org/doc/code.html.)

maxmcd 6y ago

I've been skimming the arguments so I might have missed something big, but isn't the key distinction that Deno can take anything from a URL? Go's "go get" is backed by version control systems, but you could freely point your deno at "http://dangerous.com/evil.ts" http://dangerous.com/evil.ts". I thought the concern was about the potentially problematic flexibility.

earthboundkid 6y ago
Go has a system for telling where to fetch based on the URL response. You can basically send anything if you are evil, but Go modules keep a hash of seen content (what Deno calls a lockfile), so you’d notice that it changed.
14u2c 6y ago
Isn't that the advantage though, that you can do exactly that without concern. > deno run --allow-write=~/only-evil-here http://dangerous.com/evil.ts http://dangerous.com/evil.ts

parhamn 6y ago

> GOPATH, which is smart because it turns out a huge percentage of devs don’t know what env vars are or how to set them. This gave me a laugh but it’s not fair! I’d guess most of the GOPATH outcry was the annoyance around managing automated and other non-dev environments.

Groxx 6y ago
Also at having to put your source in the gopath at its import path. So you couldn't have 'project/' and 'project2/', you had to have 'gopath1/src/path/to/project/' and 'gopath2/src/path/to/project2' or you had absolutely no isolation between things (until vendor (and that leaks (and it still requires that deep folder structure in some cases (and it took them quite a while to accept it in core tools)))). GOPATH was nothing short of a monstrosity. Its problems were truly obvious on day 1, but it lingered and infected everything.
- earthboundkid 6y ago
  I don’t agree that it was a monstrosity. I do agree that developers didn’t like having to include “extra” folders. I think even just making a GOSRC var and dropping /src would have bought good will. (Go has a GOBIN.)
- jrs95 6y ago
  I still use this directory structure and it doesn't really bother me honestly. Makes it very easy to work with multiple local repositories without having to worry about any linking or installing bullshit you have to do with other systems.
  - parhamn 6y ago
    It is certainly remarkable how long this is effective for in Golang. Libs just don't break.
- xrd 6y ago
  Are you sure you aren't discussing lisp here? :)

searchableguy 6y ago

Importmaps are available in deno behind an unstable flag. A few npm clones are using them.

dzsekijo 6y ago

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:// 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:// 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:// 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. https://golang.org/doc/code.html.)