Earlier quoted context omitted.
... catch the errors?
It was rhetorical and meant to be facetious.
On HN it's better to just share your point rather than obfuscate it with sarcasm and rhetoric.
A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
51–60 of 68 posts
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#52Earlier quoted context omitted.
It is being actively developed. Has a large pool of active contributors.
Both the SES people and the Deno people are active. I'd guess there are ~2-10 active people in both projects.
2 vs 10 is a big dif. 10 is about the size of core teams on major projects.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#53Earlier quoted context omitted.
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...
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.
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 , 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.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#54Does "secure" implies some protections against Spectre-like attacks?
V8 provides some protections against spectre-like attacks, but that's not specific to deno, as Node.js uses V8 as well.
"Secure" in this case refers to being able to not give deno access to the network or filesystem.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#55Earlier quoted context omitted.
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 At the time it was deemed to difficult to implement in Node.js after the fact, whi…
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
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).
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#56Earlier quoted context omitted.
... catch the errors?
It was rhetorical and meant to be facetious.
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.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#57Watch 10 things I regret about node. js - 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.
It is very interesting although I didn't really understand the 'security' part. The motivation seems to be twofold - some bad things have happened because of compromised npm packages and v8 happens to have a robust sandbox. This sounds like a solution looking for a vaguely defined problem. The illustrative example he gives is 'malicious linter'. Is malicious linter that important a threat?
In the example the linter itself is not malicious, but used to deliver a malicious program that can have unrestricted filesystem access. Not vague at all, see recent news on the ‘event-stream’ package being used to steal cryptocurrency wallets.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#58Earlier quoted context omitted.
It was rhetorical and meant to be facetious.
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 deci…
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.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#59What makes this different from something like https://github.com/Agoric/SES ?
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…
Thanks, that's a great summary!
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#60I 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?