The very first line of sample code is linking to Deno standard modules, basically the standard library for Deno, aiming to be feature complete enough to bring down the side of dependencies

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

Feel free to ask any questions there!

By default remote imports does allow network access, but when running the downloaded scripts, they subject to network permission settings.

Also if you are just worried about any remote imports anyways, there is a `--no-remote` (turn off http[s] resolution) and `--cached-only` (only resolve remote module if it is already downloaded and saved in cache) flag on `deno run`

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

I know people love asking when 1.0 is coming out, but please don't feel rushed! A delayed, thoughtful launch is infinitely better than an earlier rushed launch!

You probably don't need me to tell you this stuff though.. it's just annoying to see people pester every project about 1.0. I get it's probably just their excitement..

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

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?

Oh, great news! It’s closer to 1.0 than I realized. Been checking in on the project occasionally, but been waiting till the everything was more settled.

Looking forward to giving it a test drive!

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.

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 . They also do many speculative optimizations.

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

The Rust v8 wrapper used in Deno is rusty_v8: https://github.com/denoland/rusty_v8

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

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";`

You don't really need NPM hosting with Deno. What you need is an index: sources can be hosted elsewhere independently, and instead people can build sites for popular module lookups.

A package manager is different from package hosting. In the case of Deno you can still build and use third party package managers (and they might be able to utilize Deno's import-maps support to achieve some "magic")

How and does deno deals with extensions built in C/C++ for instance?

We currently support Rust message-passing based plugins. Rust sources can be fetched with Cargo or other alternative tools.

Maybe (just "maybe" for now) we will be able to support plugin imports. In that case dylibs could be directly pulled down from network just like normal files (don't take my words as official though -- we have not decided on that yet)

There have been attempts to add some util functions for loading such plugins easier: https://github.com/denoland/deno/pull/3471

Yep that is the intended Deno standard modules -- the goal is to have a standard library large enough to cover most use cases (and that this standard library would not depend on external sources), while making sure that it is independent from the Deno binary to avoid bloat and allow choices (you can definitely implement your own alternatives)