> > Secure by default. No file, network, or environment access, unless explicitly enabled. > Great, but we're talking about server software so the first thing

> > Secure by default. No file, network, or environment access, unless explicitly enabled. > Great, but we're talking about server software so the first thing any project is going to do is enable all of that. And it's not like you can trust this on the server, you'd still need to sandbox to process if you truly want isolation. See below re: static builds, but they're making decisions that render Deno much more useful for cross-platform desktop distribution ("what do you mean, cross platform scripts are already easy to distribute" LOL I mean cross-platform including Windows) than Node, or most other scripting languages, for that matter. > > Supports TypeScript out of the box. > Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps? Having it built in means your JS build Jenga tower can be a little shorter, which is great, because the JS build ecosystem is batshit crazy. TypeScript's the right horse to back because it's become a de facto standard already—its tooling is much better than Flow, for one thing, and a lot of people seem to prefer its style. It's a better choice than other compile-to-JS languages because it's very close to vanilla Javascript, to the point that you can tell it to compile to JS that looks hand-written and clearly maps to what you wrote in the TS (this is because its compilation process is mostly just stripping out all the TS stuff). To adopt something like Elm would be to ask developers to develop a completely different language, not just JS-with-static-types. Why static types built-in at all? It can allow for good advances in tooling and performance that wouldn't be available without it. > > Ships only a single executable file. > I guess that could be convenient but I'm struggling to think of a situation where installing node has ever been a problem. This is, to be blunt, fucking wonderful if you're distributing to both Unixy operating systems and Windows, especially if you don't have tight administrative control over all machines involved. Vendoring in stuff like your script runtime is brilliant for preventing all kinds of problems, and if it's a single static binary or (even better) produces static bins that bundle your script, too, then that's very easy to do. Besides, dealing with NPM (or any other language package manager—pip, etc, they're all a pain in the ass when it comes to distribution) on the user end sucks, so you're going to want to bundle everything up in one file anyway, one way or another, if you can. > > Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt). > Is this not the job of the package manager? Or does deno force you to use itself as the package manager? Will that not just bring about another npm situation in a few years? This is one thing Go got very right. Building in the basic tools is the right thing to do.