
Deno – A secure TypeScript runtime on V8 - netgusto
https://github.com/denoland/deno
======
dang
[https://news.ycombinator.com/item?id=17183241](https://news.ycombinator.com/item?id=17183241)

------
sephware
This is an excellent hindsight-2020 project, and the concept is overall an
improvement on Node, but I'm afraid the ship has sailed and Node's momentum is
too high to stop. Not that mainstream usage was ever its goal, it was
basically a proof of concept for Ryan Dahl to demonstrate how he would do
things differently if he could start over, and that yes, it would be
demonstrably better than Node. On one hand I wish TypeScript got more love,
but on the other hand its inherent unsoundness kind of makes me want something
like ReasonML[1] to win out in the long term instead.

[1] [https://reasonml.github.io/](https://reasonml.github.io/)

~~~
alx_hghs
What’s unsound about TypeScript? I’m just learning it as we use it a lot at
work

~~~
sephware
A lot of it is described in
[https://www.typescriptlang.org/docs/handbook/type-
compatibil...](https://www.typescriptlang.org/docs/handbook/type-
compatibility.html)

More examples are on
[https://github.com/Microsoft/TypeScript/wiki/FAQ](https://github.com/Microsoft/TypeScript/wiki/FAQ)

------
andrewstuart
"Ryan Dahl is fixing his Node.js design regrets with Deno"

[https://jaxenter.com/ryan-dahl-fixing-node-
deno-146190.html](https://jaxenter.com/ryan-dahl-fixing-node-deno-146190.html)

------
diegorbaquero
Worth watching "10 Things I Regret About Node.js":
[https://www.youtube.com/watch?v=M3BM9TB-8yA](https://www.youtube.com/watch?v=M3BM9TB-8yA)

~~~
sephware
And the slides:
[http://tinyclouds.org/jsconf2018.pdf](http://tinyclouds.org/jsconf2018.pdf)

------
kcorbitt

        import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts"
    

Won't this get old really quickly? Most of my Javascript files start with 3-4
imports of the form `import React from "react"`, `import { sortBy } from
"lodash"`. Having to type out the full path/version for those imports feels
like a step backwards in usability, and makes it more likely that I'll end up
with mismatched versions of dependencies.

~~~
n_ary
Not a problem if the version part is excluded. Golang uses similar
imports(think all the github.com/user/package) and seems fine.

But this could lead to a mess, as different files may end up using different
version of same package.

------
nailer
> Aims to support top-level await.

As a node developer: yum.

~~~
andrewstuart
top level await is not important.

The easiest solution to this is just put one single line of code at the top of
your application, then you can have as many awaits as you like under that.

~~~
nailer
It's more complex than just adding an IIFE, which is why Ryan mentioned it.
You can't await an import, for example.

------
Scarbutt
Why not a secure runtime on Golang instead? just curious since I saw in
another article here today that the author of Deno(also the creator of nodejs)
prefers Go for server stuff.

Leveraging JS popularity is one reason I can think of.

~~~
wakeywakeywakey
It seems like they've chosen Rust for the backend. This is a great fit in
terms of preventing data races and having a no-GC performance profile.

~~~
skybrian
JavaScript is garbage-collected. They are using Rust to avoid having two
garbage collectors.

