
Deno: JavaScript Runtime for V8 Written in Rust - alexellisuk
https://deno.land/std/manual.md
======
est31
The talk by Ryan Dahl that introduced Deno to the world:
[https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

~~~
kadfak
Overview of the talk from a comment[0] of that video:

> The goal of Node was event driven HTTP servers.

>

> 5:04

> 1 Regret: Not sticking with Promises.

> * I added promises to Node in June 2009 but foolishly removed them in
> February 2010.

> * Promises are the necessary abstraction for async/await.

> * It's possible unified usage of promises in Node would have sped the
> delivery of the eventual standartization and async/await.

> * Today Node's many async APIs are aging baldly due to this.

>

> 6:02

> 2 Regret: Security

> * V8 by itself is a very good security sandbox

> * Had I put more thought into how that could be maintained for certain
> applications, Node colud have had some nice security guarantees not
> available in any other language.

> * Example: Your linter shouldn't get complete access to your computer and
> network.

>

> 7:01

> 3 Regret: The Build System (GYP)

> * Build systems are very difficult and very important.

> * V8 (via Chrome) started using GYP and I switched Node over in tow.

> * Later Chrome dropped GYP for GN. Leaving Node the sole GYP user.

> * GYP is not an ugly internal interface either - it is exposed to anyone
> who's trying to bind to V8.

> * It's an awful experience for users. It's this non-JSON, Python adaptation
> of JSON.

> * The continued usage of GYP is the probably largest failure of Node core.

> * Instead of guiding users to write C++ bindings to V8, I should have
> provided a core foreign function interface (FFI)

> * Many people, early on, suggested moving to an FFI (namely Cantrill) and
> regrettably I ignored them.

> * (And I am extremely displeased that libuv adopted autotools.)

>

> 9:52

> 4 Regret: package.json

> * Isaac, in NPM, invented package.json (for the most part)

> * But I sanctioned it by allowing Nod's require() to inspect package.json
> files for "main"

> * Ultimately I included NPM in the Node distribution, which much made it the
> defacto standard.

> * It's unfortunate that there is centralized (privately controlled even)
> repository for modules.

> * Allowing package.json gave rise to the concept of a "module" as a
> directory of files.

> * This is no a strictly necessary abstraction - and one that doesn't exist
> on the web.

> * package.json now includes all sorts of unnecessary information. License?
> Repository? Description? It's boilerplate noise.

> * If only relative files and URLs were used when importing, the path defines
> the version. There is no need to list dependencies.

>

> 12:35

> 5 Regret: node_modules

> * It massively complicates the module resolution algorithm.

> * vendored-by-default has good intentions, but in practice just using
> $NODE_PATH wouldn't have precluded that.

> * Deviates greatly from browser semantics

> * It's my fault and I'm very sorry.

> * Unfortunately it's impossible to undo now.

>

> 14:00

> 6 Regret: require("module") without the extension ".js"

> * Needlessly less explicit.

> * Not how browser javascript works. You cannot omit the ".js" in a script
> tag src attribute.

> * The module loader has to query the file system at multiple locations
> trying to guess what the user intended.

>

> 14:40

> 7 Regret: index.js

> * I thought it was cute, because there was index.html

> * It needlessly complicated the module loading system.

> * It became especially unnecessary after require supported package.json

>

> 15:28 Talks about Deno.

[0]:
[https://www.youtube.com/watch?v=M3BM9TB-8yA&lc=UgwteTb0N1PFq...](https://www.youtube.com/watch?v=M3BM9TB-8yA&lc=UgwteTb0N1PFqnr2DqB4AaABAg)

~~~
dmix
>> * Many people, early on, suggested moving to an FFI (namely Cantrill) and
regrettably I ignored them.

A bit off-topic but Dahl referenced Cantrill here, who I figured to mean one
of the authors of DTrace, Bryan Cantrill, who I then found from his Twitter
([https://twitter.com/bcantrill](https://twitter.com/bcantrill)) just last
month started a new "computer company" which sounds super interesting,
especially with his past experience and the passion he seems to have for
attempting to solve a tough, bold problem:

[http://dtrace.org/blogs/bmc/](http://dtrace.org/blogs/bmc/)

Edit: which apparently was posted on HN with 500+ upvotes
[https://news.ycombinator.com/item?id=21682360](https://news.ycombinator.com/item?id=21682360),
regardless it's a good read worth re-mentioning here

Edit 2: Also thank you for the excellent write up, I wish every tech talk had
a text TLDR

~~~
PudgePacket
For more context, Cantrill was senior at Joyent, who has Nodejs listed as one
of their products on Wikipedia and has been the corporate sponsor of Nodejs
for a long time.

------
rubyn00bie
Anyone know what the status of this is or like how close to release 1.0 is?
I'd really like to dig in and give a try but it's hard to know just how much
time I could waste pre-1.0.

I looked on the status page and it seems like things are moving along to the
~1.0 release, but as an outsider I can't gauge if that's three months or a
year.

I'm mostly just really excited for this at there's a great deal of it (Deno)
that makes a shitload more sense to me than Node (module loading is one,
$HOME/.deno/bin is another); and being so heavily integrated with Rust appeals
to me in a big way (I actually understand Rust, but C++ always leaves me just
instantly mind-fucked).

~~~
kevinkassimo
I believe the current goal is by the end of January (and the main blocker
right now is v8 inspector support (debugging in Chrome devtools)).

However internally there are quite a few things need to refactor. Since Deno
aims for better Web spec compliance, we need an overhaul of the Worker
implementation we have right now. So likely existing API interfaces under the
Deno namespace is stabilizing soon, but many of the Web-compat APIs still need
frequent updates

~~~
leeoniya
i know you guys banned this guy [1] for trolling, but he certainly has a fast
v8/tcp stack that bypasses node's internals.

from the benchmarks, deno looks similar to node in net/http perf. is there any
specific reason you guys cannot get significantly more perf out of deno? (Alex
has always said and shown that v8 is not the bottleneck).

does v1 mean that some of the existing architectural choices are frozen and
any significant perf improvments become impossible?

[1]
[https://github.com/uNetworking/uWebSockets.js](https://github.com/uNetworking/uWebSockets.js)

~~~
kevinkassimo
TBH I am not probably the right person to answer this. Bartek has been working
on a lot of internal refactoring these days and he had some discussion with
Bert (presenter in dotjs video) on the topic. Maybe ask him in the Gitter
chatroom?

------
MehdiHK
In a GitHub thread ry mentioned, "Currently async ops are executed on the same
thread as the issuing Isolate - however I’m quite sure we can improve this and
execute async ops in different threads." [1]

Is this what I think it is? Does it mean in the future I can write 'await
fn()' and it'll run in a different thread? Or am I a fool and hoping too much?

[1]
[https://github.com/denoland/deno/issues/3003#issuecomment-53...](https://github.com/denoland/deno/issues/3003#issuecomment-534157150)

~~~
doteka
Node does this as well AFAIK, IO operations are ran on a worker pool [1]

[1] [https://blog.logrocket.com/a-complete-guide-to-threads-in-
no...](https://blog.logrocket.com/a-complete-guide-to-threads-in-node-
js-4fa3898fe74f/)

------
faitswulff
Another comment [0] provided a list of features differenting Deno vs Node, but
once it's complete, in what situations would it be more appropriate to use
Deno rather than Node?

[0]:
[https://news.ycombinator.com/item?id=22103054](https://news.ycombinator.com/item?id=22103054)

~~~
PudgePacket
I think it's intended to just be a "better node" in as many respects as
possible. Better security, more coherent module/package system, async/promises
from the start rather than hacked in, first class security/sandboxing options.

The cool stuff I think is in where Deno is different. Able to be used as a
library from other Rust or C compatible languages. Able to compile your
javascript and Deno itself together into a single binary, etc

~~~
kevinkassimo
Also scripting feels nice in Deno so far. Also the ease of using a script
written by someone else hosted on the web to do stuff, without worrying it
taking over my machine, is cool IMHO.

------
solarkraft
I thought Deno was supposed to be Typescript native?

Edit: It still supports Typescript (since TS is a superset of JS it can be a
native runtime for both, right?).

~~~
kevinkassimo
Deno does transparent compiling and caching of TS into JS. This allows
interesting behavior such as the ability to import TS files with explicit .ts
extension in JS files, e.g. `import A from
"[https://example.com/a.ts";`](https://example.com/a.ts";`)

------
dang
Discussed 7 months ago:
[https://news.ycombinator.com/item?id=20373430](https://news.ycombinator.com/item?id=20373430)

In 2018:
[https://news.ycombinator.com/item?id=17183241](https://news.ycombinator.com/item?id=17183241)

[https://news.ycombinator.com/item?id=18143572](https://news.ycombinator.com/item?id=18143572)

------
mhd
Wonder what itch this is scratching (security? RiiR/TS?). The IMHO biggest
flaw of node (no std lib) still seems present.

~~~
lioeters
I don't know, I feel like Node.js has a fairly full-featured and useful
standard library? [https://nodejs.org/api/](https://nodejs.org/api/)

\---

From the OP:

Comparison to Node.js

\- Deno does not use npm - It uses modules referenced as URLs or file paths

\- Deno does not use package.json in its module resolution algorithm.

\- All async actions in Deno return a promise. Thus Deno provides different
APIs than Node.

\- Deno requires explicit permissions for file, network, and environment
access.

\- Deno always dies on uncaught errors.

\- Uses "ES Modules" and does not support require(). Third party modules are
imported via URLs:

import * as log from
"[https://deno.land/std/log/mod.ts";](https://deno.land/std/log/mod.ts";)

~~~
mrkurt
We (fly.io) use Deno pretty intensely. We really like:

* No npm spaghetti, just requiring a URL is a win

* It'll build a lightweight static binary. Usually way smaller than the equivalent node Docker image

* The stdlib and every community lib were written at a time when async/await was the norm. So they're all very nice to use compared to wildly inconsistent node libs

~~~
lioeters
Very interesting to hear. I didn't realize Deno was "production ready", I'd
been curious about it for a long time.

Your comment inspired me to study Deno deeper and consider it for practical
use. In addition to the pros you've listed, seamless integration of TypeScript
sounds fantastic.

Would love to hear more about how Deno is used in your company!

------
maxpert
I hope at some point in time we can use Typescript's type hints to replace/add
a better JIT for v8 engine.

~~~
kevinkassimo
I remember saw something long time ago that type hints does not really offer
much performance benefit here. Also TypeScript types aren't that reliable
anyways since you can always @ts-ignore them. Real impact of TS on runtime
performance is more or less an encouragement to developers to create objects
of similar shapes that are easier to optimize.

JITs create "shapes" or "hidden classes" anyways: [https://v8.dev/blog/fast-
properties](https://v8.dev/blog/fast-properties) . They also do many
speculative optimizations.

~~~
domenicd
My understanding is that non-sound type systems are not helpful for runtime
optimizations. (In fact, to the extent that they operate at runtime at all,
they will slow things down, by adding extra checks.) Only sound type systems
give you enough guarantees to start doing optimizations with.

(TypeScript is not sound.)

------
csdreamer7
Does Dino plan to have any gui or even electron like functionality?

Google Chrome keeps changing which affects Electron. I already had one
tutorial that went out of date because of these changes.

It would be nice to use a different base, especially something that is built
upon Rust's security and correctness guarantees.

~~~
PudgePacket
It's not releasing with any GUI functionality, though in theory there's no
reason it can't go the same route as Electron :)

You might also be interested in webview, which allows programs to use the
native system webview without needing each application to bring their own copy
of a browser everywhere!

[https://github.com/zserge/webview](https://github.com/zserge/webview)

------
kevinkassimo
For people who are interested to learn more about the current status of Deno,
we have a Gitter chatroom:
[https://gitter.im/denolife/Lobby](https://gitter.im/denolife/Lobby)

Feel free to ask any questions there!

------
sriku
It isn't clear from the materials, but is a capabilities based security model
being put in place .. similar to WASI? .. or is it just the beginnings of one
with blanket `--allow-read`, `--allow-net` and such.

------
jppope
Been following this for a while... it's going to be a big deal.

------
cjbprime
I wonder what Rust is being used for here.

~~~
tbrock
Dahl wrote rust bindings for V8 and Deno itself is a rust project.

You can think of it as a large rust wrapper around C++ Javascript runtime.

~~~
kevinkassimo
The Rust v8 wrapper used in Deno is rusty_v8:
[https://github.com/denoland/rusty_v8](https://github.com/denoland/rusty_v8)

The whole privileged side (except for v8 itself) is in Rust.

------
rglover
For those not aware, this is written by Ryan Dahl, the creator of Node.js.

~~~
maxyme
And Deno is literally Node shifted 2 letters over

~~~
iknowstuff
Ö

~~~
jedimastert
Umlaut o is now my favorite emoticon.

~~~
tosh
TIL Ö

~~~
jaeh
feel free to add an

Ü

on top of that :)

------
ausjke
so is typescript the default with Deno? yes I know js is subset of ts, but
still I would like Deno default to JS instead of TS.

I never get the point of TS, as long as JS ES2023(or whatever) got some typing
in place, I will stick with JS for good.

------
Snelius
Will wait he drop this one for a new "Endo". Omg, nodejs just works, keep
improvements.

------
trias
\- no file system access \- no internet access \- no environment access

also loads code from the internet and runs it no questions asked.

~~~
PudgePacket
.... except it does ask questions

Goal 2

Provide Secure Defaults

    
    
        Unless specifically allowed [by the user], scripts can't access files, the environment, or the network.

~~~
wmf
That doesn't mean what you think. See
[https://deno.land/std/manual.md#linking-to-third-party-
code](https://deno.land/std/manual.md#linking-to-third-party-code)

"Note that we did not have to provide the --allow-net flag for this program,
and yet it accessed the network. The runtime has special access to download
imports and cache them to disk."

~~~
PudgePacket
I don't understand what you're trying to say?

Deno the privileged runtime can do these things, but the scripts/code you get
it to run cannot do these things without permission.

Specifically I was talking about this section of the posters comment "runs it
no questions asked". No, it will _not_ be run no questions asked.

