> Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware.

This is a price of the inherent decentralized idea that the Deno team has. I foresee tooling or other forms of validation in the future to prevent things like this, but until then, just as a team requires discipline to not do things like blindly updating all of their ^ dependencies in Node world, `npm install`ing a package with a gigantic and risky dependency graph, deleting the lockfile, or mistyping the name of a package (`npm install reactt`), some degree of discipline is necessary with Deno as well.

> Just because _some_ people are using it in production doesn't mean it's a good idea.

Maybe their use cases are different than yours, and maybe the benefits of Deno outweigh the negatives given their circumstances! The ecosystem argument is always silly because if X is popular before Y is, X will have a more vibrant ecosystem. Deno apparently has npm interop, though, I have not used it.

> So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch.

I am also a fan of Cloudflare Workers. That doesn't change the fact that I am still productive with Deno Deploy.

> Apart from the things above, just take a look at any discussion about supply chain security...

Thanks, but this is not a specific answer.