Deno – A secure TypeScript runtime on V8 | Hacker News Reader

Deno – A secure TypeScript runtime on V8

github.com

25 pointsnetgusto18 comments

https://news.ycombinator.com/item?id=17183241

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/

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

A lot of it is described in https://www.typescriptlang.org/docs/handbook/type-compatibil...

More examples are on https://github.com/Microsoft/TypeScript/wiki/FAQ

TypeScript is a structural typing model vs nominal one, such as Java, which we are more used to. Not that one is more sound than the other, just different approaches.

I actually like the structural system a lot, and found that combined typescript expressiveness, typing a code base with TS is much more intent driven and requires much less contortionism that a class-for-everything nominal system such as Java. In fact, we ported one of our java backend to node/TS, 40% less code, and as typed if not more. Also, there are simple ways to bring some of the nominal characteristics when needed, but in a language like JS where object literal is a intrasic part of the language, a structural typing system is great fit.

So, yes, their are different approach, but not sure soundness is a good description of those differences.

Now, if TypeScript is used to code JavaScript ”a la” Java, then yes, it could be seen as a loss of functionality.

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

https://jaxenter.com/ryan-dahl-fixing-node-deno-146190.html

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

And the slides: http://tinyclouds.org/jsconf2018.pdf

    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.

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.

> Aims to support top-level await.

As a node developer: yum.

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.

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

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.

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.

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

There used to be one.

https://news.ycombinator.com/item?id=17183241

https://github.com/denoland/deno/pull/276

Wasn’t able to find the motivation yet.

the double GC problem is too worrying to invest more into it.

https://github.com/denoland/deno/pull/276#issuecomment-39932...

Reply on news.ycombinator.com