deno is v1 now https://deno.land/v1

It looks promising... I am a bit unsure about whether or not the dependency management is very secure. Loading code from random urls on the web? What happens if the source goes down or something?

Oh god, *complete* reliance on a CDN for external dependencies?

@python3 it works like Go in that the file is saved locally despite you having it referenced as a URL in your source code

@PrivateGER see above

@catholic-emacs Yeah but with Go you eventually compile that thing, and distribute a binary. With deno you need to access external sources everywhere you want to run your software.

@hitko once, at least.

@catholic-emacs Yeah, and since it's a random file on the internet, it's much more likely to change / disappear / be taken over some hostile entity than a package on a proper repository. Also since nobody enforces proper versioning and imutability of published versions, there's no way to know what this file will do when you install your project on a new machine next week.

I know all these things happened on NPM already. The difference is when that happens on NPM, there's a team available to fix it and prevent it from happening in the future; when it happens on some random site because Joe didn't renew a domain and someone else took it, you can all just go fuck yourself because nobody will ever fix that.

@hitko why so much skepticism? Go has been using this model with much successes

@catholic-emacs Because there's a load of differences between the way Go does it and the way Deno does it.

Go module is a repository managed by source control management like git or mercurial. To import a Go module you need repository url and version, which has to follow semantic versioning and exist as a tag within the repository.

Deno module is a url, and the only way of versioning is by making the version a part of the url. There's no need to use source code management to ensure each version is (at least theoretically) immutable snapshot of code, there's no need to follow proper versioning, there's no need to host it on a proper platform - you can just share a Dropbox link, and mark my words, some people will do exactly that.

@hitko Plus with Go only package developer installs dependencies, and if one goes missing / changes / whatever, they're there to fix it before publishing a binary to the end user; with Deno, end user needs to install dependencies as well, and if something's wrong with dependencies, they have to reach out to the developer to fix it.

As a result when someone stops maintaining a project, with Go the end user can still use released binaries potentially for years to come. With Deno unmaintained projects can't be installed and used as soon as one of the (deep) dependencies breaks.

Thanks!!