10 ms·

Deno: JavaScript Runtime for V8 Written in Rust

319 points by alexellisuk 7y ago

rglover 7y ago
For those not aware, this is written by Ryan Dahl, the creator of Node.js.
- maxyme 7y ago
  And Deno is literally Node shifted 2 letters over
  - iknowstuff 7y ago
    Ö
    - jedimastert 7y ago
      Umlaut o is now my favorite emoticon.
      - tosh 7y ago
        TIL Ö
        jaeh 7y ago
        feel free to add an Ü on top of that :)
  - unlinked_dll 7y ago
    Must be a release build, otherwise that'd panic before it wrapped around.
mhd 7y ago
Wonder what itch this is scratching (security? RiiR/TS?). The IMHO biggest flaw of node (no std lib) still seems present.
- lioeters 7y ago
  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 7y ago
    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
    - samblr 7y ago
      Can you give size difference between both?
    - lioeters 7y ago
      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!
  - throwawayblahhh 7y ago
    > I don't know, I feel like Node.js has a fairly full-featured and useful standard library? IMO not really. We have many Java and JS projects where I work, I can't find a single Java project that has bigger dependencies than even our smallest JS project, or even an empty "create react app". One of our Java projects is 200k+ lines and still has smaller dependencies than create react app or a empty project created with angular cli. In JS, it's normal to pull in 500+ libraries and this is only because the standard library is so lacking. Our Java projects, even massive ones, pull in less than 100. In Java you also have Guava and Apache Commons. Those cover about 95% of data structure needs for a project not covered by the JVM. JS has nothing comparable. People lament about how "big" the JVM is, but you trade complexity of the VM for complexity of your own app. In practice Java projects are smaller and use less space and memory because your dependencies aren't using 10 different libraries to pad whitespace. This also makes it much easier to mentally transition between Java projects. If they were built in the last decade, they're probably using the standard library, Guava/Commons, hibernate, and some HTTP interface. I can move between Java projects at work no problem, but if it's Node or front-end 90% of the time I'm going to spend a few days learning a new framework to get anything done. Small standard libraries are very harmful to the ecosystem. I hope to God they do it right with Deno, batteries included like Python and Java
est31 7y ago
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 7y ago
  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=UgwteTb0N1PFqnr2DqB4AaABAg https://www.youtube.com/watch?v=M3BM9TB-8yA&lc=UgwteTb0N1PFq...
solarkraft 7y ago
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?).
- dstaley 7y ago
  No, it just supports TypeScript out of the box.
- kevinkassimo 7y ago
  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";`
trias 7y ago
- no file system access - no internet access - no environment access also loads code from the internet and runs it no questions asked.
- frank2 7y ago
  When invoking the deno command, the user has the option to grant or deny the command access to the file system, internet, environment. >loads code from the internet and runs it no questions asked I think this is a reference to the fact that Deno uses "Ecmascript modules" referenced as URLs the same way modern browsers do.
- wmf 7y ago
  loads code from the internet and runs it no questions asked Like every "modern" package manager? I think that's a lost cause.
  - Snelius 7y ago
    What about versions of that url based packages?
- leeoniya 7y ago
  yeah i thought that, too. but assuming the loaded code has no access to any of those things either, then i'm not sure what the concern is. though if you gave network access to your code and it loaded other code from the internet which inherited those permissions, that's pretty terrifying (especially since it's not some edge case) - i assume this has been thought through, since it's so obvious.
- PudgePacket 7y ago
  .... 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 7y ago
    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."
z3rgl1ng 7y ago
> Among other things, Deno is a great replacement for utility scripts that may have been historically written with bash or python. Maybe “would like to be the replacement” would be more honest here.
cjbprime 7y ago
I wonder what Rust is being used for here.
- tbrock 7y ago
  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 7y ago
    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.
- zozbot234 7y ago
  > I wonder what Rust is being used for here. • "Written in Rust" • Gets top spot on HN frontpage ...just a coincidence?
  - chrisco255 7y ago
    Eh, a significant product that is relevant to both the JavaScript community and the Rust community deserves top billing here.
  - 40four 7y ago
    The project was originally written in Go, then they decided to switch to Rust after a while.
- dentemple 7y ago
  It's probably for the same reason that Node.js uses C++. Javascript is not understood natively by your hardware, so bindings are created to facilitate interaction between the programmer and lower level processes.
faitswulff 7y ago
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 7y ago
  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 7y ago
    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.
- austincheney 7y ago
  1. A secure environment. You must authorize access to libraries like the file system or network interface. By preventing access by default you can write systems automation that is arbitrary computation resident in memory not intentionally leaking outside the computer. 2. Management sanity. Deno is written in TypeScript, so it doesn't need something like @types/node to interface with TypeScript the way Node does. This is rarely problematic, but when it does come up its painful. For example in Node the http response type is http.incomingMessage. The port number of the originating server is in there at response.socket.server.port, but @types/node currently thinks response.socket is typed to net.socket which doesn't have a server property and so you get a compile error. 3. Distribution sanity. If you download the @angular/cli framework from NPM it is, at this time, 250 NPM dependencies and 26.6mb for just the CLI interface. The full framework is closer to 90mb and 1140 NPM dependencies. That is insanity. The Node binary plus installer for Windows is only 18.6mb. Deno wants to solve this by wrapping a project into a single archive for package distribution. Hopefully, that will result in smaller packages where dependencies are fewer and intentional instead of the nonsense of stuff like NPM or Maven. 4. ES Modules are a very nice way to manage and organize code. I am using them now with a large Node project I am writing without Node's silly conventions for ES modules. In Node ES modules are experimental and there are virtually no dependencies available that are exclusively using ES modules and feature a TypeScript types library in Node, so if you go down that path you must be dedicated.
maxpert 7y ago
I hope at some point in time we can use Typescript's type hints to replace/add a better JIT for v8 engine.
- kevinkassimo 7y ago
  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 7y ago
    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.)
- zozbot234 7y ago
  I'd think V8 itself could be replaced with Cranelift once that gains a few more features.
Snelius 7y ago
Will wait he drop this one for a new "Endo". Omg, nodejs just works, keep improvements.
csdreamer7 7y ago
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 7y ago
  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
ausjke 7y ago
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.
rubyn00bie 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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?
jppope 7y ago
Been following this for a while... it's going to be a big deal.
kevinkassimo 7y ago
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!
MehdiHK 7y ago
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-534157150 https://github.com/denoland/deno/issues/3003#issuecomment-53...
- swsieber 7y ago
  That's how I read it. It might happen selectively based on some heuristic though (that would be my guess).
- wruza 7y ago
  I guess it is about asyncing to a different isolate+thread, not multithreading a single one. Locking issues do not go away just because it is javascript, rust and 2020.
- doteka 7y ago
  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-node-js-4fa3898fe74f/ https://blog.logrocket.com/a-complete-guide-to-threads-in-no...
- crabmusket 7y ago
  I think it's likely that in this context, "ops" refers to the low level runtime primitives Deno provides and implements in Rust. E.g. read bytes from a file. I doubt you could transparently multithread `await` without clashing with JS's semantics.
dang 7y ago
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
sriku 7y ago
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.

319 points by alexellisuk 7y ago

rglover 7y ago

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

maxyme 7y ago
And Deno is literally Node shifted 2 letters over
- iknowstuff 7y ago
  Ö
  - jedimastert 7y ago
    Umlaut o is now my favorite emoticon.
    - tosh 7y ago
      TIL Ö
      - jaeh 7y ago
        feel free to add an Ü on top of that :)
- unlinked_dll 7y ago
  Must be a release build, otherwise that'd panic before it wrapped around.

mhd 7y ago

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

lioeters 7y ago
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 7y ago
  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
  - samblr 7y ago
    Can you give size difference between both?
  - lioeters 7y ago
    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!
- throwawayblahhh 7y ago
  > I don't know, I feel like Node.js has a fairly full-featured and useful standard library? IMO not really. We have many Java and JS projects where I work, I can't find a single Java project that has bigger dependencies than even our smallest JS project, or even an empty "create react app". One of our Java projects is 200k+ lines and still has smaller dependencies than create react app or a empty project created with angular cli. In JS, it's normal to pull in 500+ libraries and this is only because the standard library is so lacking. Our Java projects, even massive ones, pull in less than 100. In Java you also have Guava and Apache Commons. Those cover about 95% of data structure needs for a project not covered by the JVM. JS has nothing comparable. People lament about how "big" the JVM is, but you trade complexity of the VM for complexity of your own app. In practice Java projects are smaller and use less space and memory because your dependencies aren't using 10 different libraries to pad whitespace. This also makes it much easier to mentally transition between Java projects. If they were built in the last decade, they're probably using the standard library, Guava/Commons, hibernate, and some HTTP interface. I can move between Java projects at work no problem, but if it's Node or front-end 90% of the time I'm going to spend a few days learning a new framework to get anything done. Small standard libraries are very harmful to the ecosystem. I hope to God they do it right with Deno, batteries included like Python and Java

est31 7y ago

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 7y ago
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=UgwteTb0N1PFqnr2DqB4AaABAg https://www.youtube.com/watch?v=M3BM9TB-8yA&lc=UgwteTb0N1PFq...

solarkraft 7y ago

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?).

dstaley 7y ago
No, it just supports TypeScript out of the box.
kevinkassimo 7y ago
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";`

trias 7y ago

- no file system access - no internet access - no environment access also loads code from the internet and runs it no questions asked.

frank2 7y ago
When invoking the deno command, the user has the option to grant or deny the command access to the file system, internet, environment. >loads code from the internet and runs it no questions asked I think this is a reference to the fact that Deno uses "Ecmascript modules" referenced as URLs the same way modern browsers do.
wmf 7y ago
loads code from the internet and runs it no questions asked Like every "modern" package manager? I think that's a lost cause.
- Snelius 7y ago
  What about versions of that url based packages?
leeoniya 7y ago
yeah i thought that, too. but assuming the loaded code has no access to any of those things either, then i'm not sure what the concern is. though if you gave network access to your code and it loaded other code from the internet which inherited those permissions, that's pretty terrifying (especially since it's not some edge case) - i assume this has been thought through, since it's so obvious.
PudgePacket 7y ago
.... 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 7y ago
  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."

z3rgl1ng 7y ago

> Among other things, Deno is a great replacement for utility scripts that may have been historically written with bash or python. Maybe “would like to be the replacement” would be more honest here.

cjbprime 7y ago

I wonder what Rust is being used for here.

tbrock 7y ago
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 7y ago
  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.
zozbot234 7y ago
> I wonder what Rust is being used for here. • "Written in Rust" • Gets top spot on HN frontpage ...just a coincidence?
- chrisco255 7y ago
  Eh, a significant product that is relevant to both the JavaScript community and the Rust community deserves top billing here.
- 40four 7y ago
  The project was originally written in Go, then they decided to switch to Rust after a while.
dentemple 7y ago
It's probably for the same reason that Node.js uses C++. Javascript is not understood natively by your hardware, so bindings are created to facilitate interaction between the programmer and lower level processes.

faitswulff 7y ago

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 7y ago
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 7y ago
  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.
austincheney 7y ago
1. A secure environment. You must authorize access to libraries like the file system or network interface. By preventing access by default you can write systems automation that is arbitrary computation resident in memory not intentionally leaking outside the computer. 2. Management sanity. Deno is written in TypeScript, so it doesn't need something like @types/node to interface with TypeScript the way Node does. This is rarely problematic, but when it does come up its painful. For example in Node the http response type is http.incomingMessage. The port number of the originating server is in there at response.socket.server.port, but @types/node currently thinks response.socket is typed to net.socket which doesn't have a server property and so you get a compile error. 3. Distribution sanity. If you download the @angular/cli framework from NPM it is, at this time, 250 NPM dependencies and 26.6mb for just the CLI interface. The full framework is closer to 90mb and 1140 NPM dependencies. That is insanity. The Node binary plus installer for Windows is only 18.6mb. Deno wants to solve this by wrapping a project into a single archive for package distribution. Hopefully, that will result in smaller packages where dependencies are fewer and intentional instead of the nonsense of stuff like NPM or Maven. 4. ES Modules are a very nice way to manage and organize code. I am using them now with a large Node project I am writing without Node's silly conventions for ES modules. In Node ES modules are experimental and there are virtually no dependencies available that are exclusively using ES modules and feature a TypeScript types library in Node, so if you go down that path you must be dedicated.

maxpert 7y ago

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

kevinkassimo 7y ago
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 7y ago
  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.)
zozbot234 7y ago
I'd think V8 itself could be replaced with Cranelift once that gains a few more features.

Snelius 7y ago

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

csdreamer7 7y ago

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 7y ago
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

ausjke 7y ago

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.

rubyn00bie 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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?

jppope 7y ago

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

kevinkassimo 7y ago

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!

MehdiHK 7y ago

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-534157150 https://github.com/denoland/deno/issues/3003#issuecomment-53...

swsieber 7y ago
That's how I read it. It might happen selectively based on some heuristic though (that would be my guess).
wruza 7y ago
I guess it is about asyncing to a different isolate+thread, not multithreading a single one. Locking issues do not go away just because it is javascript, rust and 2020.
doteka 7y ago
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-node-js-4fa3898fe74f/ https://blog.logrocket.com/a-complete-guide-to-threads-in-no...
crabmusket 7y ago
I think it's likely that in this context, "ops" refers to the low level runtime primitives Deno provides and implements in Rust. E.g. read bytes from a file. I doubt you could transparently multithread `await` without clashing with JS's semantics.

dang 7y ago

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

sriku 7y ago

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.