
Deno, a secure TypeScript runtime using V8 and Go - remyrylan
https://github.com/ry/deno
======
remyrylan
Worth noting, this is from the creator of Node.js, Ryan Dahl (not me - just
sharing). The project is in very early stages, but considering it's from
Ryan... it's definitely a project to keep an eye on.

~~~
partycoder
Not exactly sure why you would want to provide JavaScript scripting for Go. Go
has different concurrency primitives and a different threading model, and that
threading model is one of the biggest selling points of Go.

I highly doubt this would be "the next node", if that is the intention. If you
want to use Go, just use Go.

~~~
chatmasta
You can use it as a scripting language for your app. For example, a go binary
with customizable hooks scripted in JS. That way anyone who knows JS can
customize the binary for their specific use case.

~~~
murukesh_s
Like openresty/Nginx with Lua integration. JavaScript is way more popular than
Lua, so this have wide possibilities..

------
nedp
Just realized the creator just scrambled the word "node" to have a new name.

~~~
jazoom
At least he didn't call it "Done"

------
bigdubs
Finally, golang gets user accessible generics.

------
chatmasta
This is from the creator of node. Is that you?

I was playing with v1 of this project (the non-TS one). Super excited to see
progress on it. What are your plans?

~~~
remyrylan
Not me, just sharing.

------
weberc2
Lol "Status: segfaulty"

~~~
exikyut
Mmm. Some may find that scary; I'd make it a link to an issue
explaining/tracking what exactly causes it.

~~~
WorldMaker
Roadmap suggests it has something to do with source maps?

------
Blackstone4
What is this? A Node.js runtime equivalent for TypeScript? But written in Go
and V8?

Is it single threaded, non-blocking IO? Or will it more closely aligned with
Go coroutines? i.e. do I have to deal with callbacks and/or async/await?

~~~
dfischer
Looks like it's aiming to be async/await compliant but dunno how that is
implemented.

------
kodablah
What kind of performance hit do you incur on something like file read
serializing in and out of protobuf? Also, what is the problem this is trying
to solve when it says "secure"? Obviously the code is not that secure because
TypeScript is a bit loose on purpose (so, why TypeScript and not just a Go
sandbox?). From reading, it seems to solve a problem of restricting local
system access, so it's going to run unprivileged code? Surely there are many
other exploitation factors such as running up the CPU...the primary use case
would be ideal to help me understand.

~~~
bastawhiz
> Surely there are many other exploitation factors such as running up the
> CPU...the primary use case would be ideal to help me understand.

You're probably running untrusted JavaScript in your browser right now. The
difference between the V8 in Node and the V8 in your browser is that one is
heavily locked down and the other can do essentially whatever the OS lets it.

If you have untrusted code to run, you can eliminate a whole class of security
concerns by just not having a way for the code to do those things (i.e.,
making syscalls it shouldn't, forking, reading and writing to the disk or
network, etc.). Sure, resource use can be an issue, but that's a problem
that's more easily solvable further up the stack with VMs or containers. Just
putting an instance of Node running untrusted code in a VM doesn't solve much,
since the mechanism whereby you give it input and collect output can be
manipulated by the untrusted code itself.

By making the runtime secure, you get the security of the browser (i.e., being
able to visit a website without having to wipe your machine), but designed to
run in a server environment.

~~~
le-mark
_but that 's a problem that's more easily solvable further up the stack with
VMs or containers._

Everyone keeps saying this, let containers handle cpu/heap but I keep asking
myself, is it really optimal?

~~~
bastawhiz
I mean, it certainly depends. But relying on your interpreter to manage CPU
scheduling and memory use is almost certainly less ideal than letting your
OS/hypervisor do that for you.

------
mhd
Binary size 55 meg, compared to Node's 30. Is this an artifact of Go's
"dynamic linking considered harmful" approach or does it have some additional
functionality I'm missing?

~~~
lloeki
> Go's "dynamic linking considered harmful" approach

If anything this is only partially true: _" Package plugin implements loading
and symbol resolution of Go plugins."_

[https://golang.org/pkg/plugin](https://golang.org/pkg/plugin)

------
xab9
Can someone compare it with ts-node?

If I get it right, ts-node is just a transpiler, but deno runs "proper" ts?

~~~
dfischer
Exactly what it seems like

------
z3t4
I guess the idea is to use URL's for importing packages. And have an extra
security layer in the runtime.

I've done some concept/prototype for this but in the browser, and the main
complaint is that it takes a few extra ms the first time you run the program.
But as this is meant for servers and not impatient users, the extra startup
time should not be a big issue.

~~~
scottmf
Importing URLs is how ES modules work afaik

~~~
WorldMaker
Right, the pluggable Loader spec [1] can keeps getting kicked down the road,
and the Browsers haven't agreed yet on Node-style or non-URL-based loading. To
the Browsers, URLs "just work" and is how they've always done things, and
figuring out Node-like package boundaries or mapping package names to URLs
hasn't seemed like a priority to them yet.

[1] [https://github.com/whatwg/loader](https://github.com/whatwg/loader)

------
mohamedmansour
Ryan Dahl reserved the domain too, expect
[http://denojs.org](http://denojs.org) to be the main website to this project!

------
pitaj
README doesn't specify, so I'll ask: does anyone know how it supports TS? Does
it just strip out all the TS stuff and pipe it into the parser?

~~~
mxvzr
looks like it is using the typescript API to compile the TS code at runtime

------
ihsw2
Is this to add a scripting language to Go, like Lua is to Redis? It's a little
unclear.

~~~
randomdata
It would seem that the goal is to be modernized node that defaults to
Typescript instead of Javascript and uses vgo-style package management instead
of npm (or similar).

~~~
elankeeran
using go then directly code in Go.

