
A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio - GutenYe
https://deno.land/
======
kevinkassimo
As a contributor to Deno, I am actually quite surprised that this got
resurfaced on Hacker news after the hype June last year.

That being said, I suggest checking out this video (recorded this April) for
updated information about Deno, since things have changed quite a bit since
the initial announcement:
[https://youtu.be/z6JRlx5NC9E](https://youtu.be/z6JRlx5NC9E)

(Edit: fixed link, posted the wrong one. Why would YouTube think I want to
share ads...)

~~~
kreetx
Curious about deno's development stage: can the brave already run it in
production, or there are probably too many breaking changes in the pipe that
it's better to wait?

~~~
inglor
The brave? Sure - but there will likely be breaking changes. I actually run a
small deno server in production for a non critical service and it's been
working out fine :]

------
LunaSea
As a long time Node.js developer I took a look at the project but it's still a
really half-baked implementation of the security flags. You almost always end
up flipping all security switches off because your application needs every
feature (network, filesystem, etc).

No package signing, no flags per module, no syscall whitelisting, etc.

~~~
kevinkassimo
You turn all permissions on if you are actually using it as if it is Node for
writing servers. But in the case when you are using a (potentially untrusted)
code snippet to perform certain operations (like encode/decode base64 values),
you do might want a sandbox. (For the case of Node-like usage, we actually
also have a basic implementation of whitelisted directories/files for certain
permissions, though not perfect atm)

We have also discussed about possibilities of implementing an in-memory file
system. (Maybe we will also bring sessionStorage to Deno)

Flags per module is slightly trickier, while whitelisting of certain feature
is trivial to implement.

Package signing is indeed a topic that Deno contributors need to discuss
further and possibly finding a solution.

~~~
LunaSea
Sure but logic doesn't exist in a vacuum so in most cases you are going to
import / export your input data or your results to the filesystem or through
the network.

I actually suggested a more granular, per-module approach to this during the
Node Forward and IO.js debacle years ago: [https://github.com/node-
forward/discussions/issues/14](https://github.com/node-
forward/discussions/issues/14)

At the time it was deemed to difficult to implement in Node.js after the fact,
which makes sense of course. But I'm disappointed that Deno didn't go for a
more bolder, more secure approach. The current system seems pretty pointless.

~~~
kevinkassimo
It is actually more interesting about the definition of “per module”, because
technically every single file is its very own module from the view of V8, and
is reinforced in Deno since we are trying to be web compatible, so there is
not even a package.json-like construct for you to identify the “root” of any
library, more so as there is no more index.js magical resolution

~~~
snek
I'm really sad that I lost my gist on this, but I was working on a system in
Node.js for defining the capabilities of modules in an es module graph (as you
suggest) where there might not be defined package boundaries. The
implementation complexity (required changes to upstream V8) resulted in us
going with node policies as they are today.

I don't remember the exact API, but basically an es module graph is a directed
graph (e.g. edges have a _direction_ ), and because there is only one
entrypoint in node, we can therefore create a hierarchy of modules. From this
point on, you basically start at the root with X permissions, and from there
each module can reduce the permissions of modules they import (or they can
reduce their own permissions, but they can't raise them after that obviously).

~~~
mahmoudimus
This looks interesting. How did you lose the gist? You just can't find it on
[https://gist.github.com/](https://gist.github.com/)?

------
tfolbrecht
For the inevitably "what differentiates this from node?"

Single executable Allows imports from url File system & network Sandboxing is
controlled with flags Dies on uncaught errors

[https://deno.land/manual.html#introduction](https://deno.land/manual.html#introduction)

~~~
carlmr
>Dies on uncaught errors

how can JS programmers deal with this?

~~~
PudgePacket
... catch the errors?

~~~
carlmr
It was rhetorical and meant to be facetious.

~~~
novaleaf
on node, this can actually be very difficult or even impossible if using 3rd
party libraries.

For example, some node internals like networking require the invoker to attach
to some obscure .on("error") event to avoid uncaught errors. and a lot of the
time these 3rd parties are not aware of it.

I'm all for deno being built from the ground up to properly crash on uncaught
errors. Silent ignoring is a really stupid decision.

~~~
spion
I never understood why this is necessary. Using promises means you get to use
try-with-resources style construct for handling non-memory resources safely.
As such you no longer need to crash on uncaught errors, except errors
pertaining to resource disposal.

~~~
novaleaf
i think the reason is that, in my example of networking, the network i/o is an
"interupt" kind of event, that is triggered outside of normal execution. like
if there's a socket timeout.

probably didn't have to be designed this way, but it was designed pre-promises
and I guess they are lothe to change it.

------
lajawfe
Watch 10 things I regret about node. js -
[https://youtu.be/M3BM9TB-8yA](https://youtu.be/M3BM9TB-8yA) from the creator
of both node and deno to undersatnd his motivations behind the deno project. A
very intriguing talk.

~~~
29athrowaway
> Access between V8 (unprivileged) and Rust (privileged) is only done via
> serialized messages defined in this flatbuffer.

Expect to see this in "n things I regret about deno"

~~~
spraak
Can you explain why?

~~~
29athrowaway
Every deno API function call goes through flatbuffer serialization +
deserialization + more steps. Sounds like a lot of overhead.

------
xtreak29
Ryan Dahl, creator of node.js started this project and is also a lead
contributor.

------
dlbucci
Is this a new site, or did the project recently reach a milestone, or is this
just resurfacing?

I'm really excited about this project, especially the first-class TypeScript.
Could easily see it replacing node for me!

------
anaphor
What makes this different from something like
[https://github.com/Agoric/SES](https://github.com/Agoric/SES) ?

~~~
inglor
SES builds on capability theory to let you run "adversarial" code together
with your trusted code safely.

Deno is a runtime that aims to isolate the code from the system amongst other
issues.

SES uses a proof over the JS grammar with induction, Deno does isolation by
not giving any OS level access to your code.

Neither are particularly complete and are mostly orthogonal. Both are looking
for people to help with them :]

~~~
anaphor
Thanks, that's a great summary!

------
kodablah
I admittedly haven't researched too deeply, but are there any examples/docs on
embedding Deno in another Rust program and/or writing/exposing Rust libs with
a TS API?

~~~
limsup
[https://crates.io/crates/deno](https://crates.io/crates/deno)

------
siempreb
> A Secure Runtime for JavaScript and TypeScript

So, does it support a specific ECMAscript version? Or am I restricted to the
Typescript JS definition? This is confusing..

~~~
JeremyBanks
Nobody's support strictly matches a specific ECMAScript version.

------
ComodoHacker
Does "secure" implies some protections against Spectre-like attacks?

~~~
fanf2
No, it is about how v8 is sandboxed

------
unictek
Careful with Deno, performance is still low: [https://user-
images.githubusercontent.com/3397140/48649635-8...](https://user-
images.githubusercontent.com/3397140/48649635-89060d00-e9f3-11e8-9447-d4dbd050a310.png)

~~~
inglor
That's just FUD through a synthetic benchmark by the person who wrote uWS
after he approached Ryan and Ryan wouldn't do everything he asked for...

~~~
unictek
Running a local benchmark to compare Node.js and Deno gave me the same
magnitude of performance difference. I like the concepts behind Deno but the
performance should stay a top priority. Even more for a new technology that is
looking for future adoption. If Deno gets faster than Node.js, I adopt it. If
it stays 5x less performant than Node.js, I skip it.

~~~
kevinkassimo
Are you running deno 0.10.0 versus Node? Since there has been some internal
refactoring it should now be 80% wrt basic http req/sec (ref:
[https://deno.land/benchmarks.html#all](https://deno.land/benchmarks.html#all)
, though the benchmark might have not covered everything)

Overhead from Flatbuffers is a major reason of the slowdown and we are seeking
to get rid of it.

------
xvilka
Would be nice also to have the V8 implementation in Rust as well.

~~~
wereHamster
You mean _JavaScript_ implementation in Rust. V8 is one of the many
implementations that is written in C++.

~~~
spraak
I think the parent means they wish V8 were in Rust instead of C++

