Personal anecdote: I've fallen in love with Deno as a scripting solution for my desktop machine. It is way more powerful than shell scripting while also being way more portable and clean than a Python or Node script (assuming you end up using at least one dependency, a very common situation in Node).

I know someone's going to ask about permissions making the invocation process a pain, so here's my advice for that: embed the permissions flags in the shebang line!

Oh the shebang line is a really nice tip I didn't think about!

Something worth noting is that Deno also has permission APIs that let you query the current permission status and interactively ask for more: https://deno.land/manual/runtime/permission_apis#request-per...

not sure what you mean by that. would you mind giving an example shebang line that does this?

Here you go! One example Deno script with permissions embedded in the shebang line:

  #!/usr/bin/env -S /usr/bin/deno run --allow-net=api.github.com
  const jsonResponse = await fetch("https://api.github.com/users/denoland");
  const jsonData = await jsonResponse.json();
  console.log(jsonData);

Ah, I thought you were referring to filesystem permissions, which confused me!

This makes sense. Thanks!

I see Deno getting a lot of play here, and I think rightfully so. The recent globally distributed chat example in like 20 lines of code is basically the level of accessibility I like seeing brought to otherwise very complicated distributed systems setups.

That said how is Deno being seen in relation to Node, iirc Deno is being made to correct on a lot of the issues Node originally had but I’m curious about adoption and how this is going to fit in the JS world where Node has become so cemented, what’s the killer feature to move those people over?

Or is that not the play, will this peacefully coexist?

I can only speak from a node developer perspective but deno makes some promises that I would consider absolute killer features should they work as advertised:

- no hassle with `node_modules`

- no hassle with `npm install` and `npm ci`

- no hassle with `package-lock.json`

- no hassle with `node-gyp`

- no hassle with setting up Typescript

On the nice to have side I would mention:

- opinionated take on linting, testing and formatting

- possibility to compile into self-contained executables

> possibility to compile into self-contained executables

That it can already do this is what brought me into doing some stuff with deno. It's just deno compile to make a self contained executable (don't forget permission flags). It's a bit large at over 40 MB, but honestly that's not something I'm going to care too much about given how straightforward and easy it is and since it's not that large.

Deno can compile into self-contained executables: https://deno.land/manual@v1.16.0/tools/compiler

Thank you Grimm for beating me to the punch. Being working with a company dealing with sensitive data. who are concerned about the security of the npm package system, especially with the recent rc/roc exploits. Have any company actually moved from node to deno successfully in production? Would really appreciate some links and references to stories like that as we are also considering moving node -->>> deno.

Where are we at with Deno in terms of gotchas? Can it be used comfortably end-to-end for an average project? Does it have enough features implemented that you don't end up needing to find workarounds in the middle of a project?

It's great that startTls has been stabilized! That will make it so a lot more can be done without --unstable.

The localStorage thing feels like a change in the security model. Unless I'm missing something, now without any permissions a program can save data between calls. I thought that without --allow anything it would be close to a pure function. I think it's easily worked around by specifying a temporary localstorage when running a program you want sandboxed more fully.