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.
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.
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.
Is that the case? I thought it might have been, but then took a gander at the "Show" tab and noticed other people were clearly submitting stuff with the [Show HN] prefix when they weren't the original author.
Apologies if I screwed up. Definitely not trying to take credit for Ryan's work.
I'm pretty sure it is for showing your own work, but I wouldn't worry about it. The "Show" label is relatively minor, and this is certainly an interesting project to share!
There's a link to the rules/guidelines at the top of the "show" page:
Show HN's definitely have a prestige because we think it's the author's debut of the project, feel like we're helping out a community member, and expect them to be fielding answers in the comments.
Else everything is a Show HN. Like Show HN: Google's new privacy policy. ;)
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).
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.
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.
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.
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.
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.
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?
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?
Not me, just sharing.
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.
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.
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.
Like openresty/Nginx with Lua integration. JavaScript is way more popular than Lua, so this have wide possibilities..
I thought the whole point of Show HN was for the creator to post their own project so that we can then talk to them about it.
It doesn't make sense to create Show HN for any ol project.
Is that the case? I thought it might have been, but then took a gander at the "Show" tab and noticed other people were clearly submitting stuff with the [Show HN] prefix when they weren't the original author.
Apologies if I screwed up. Definitely not trying to take credit for Ryan's work.
I'm pretty sure it is for showing your own work, but I wouldn't worry about it. The "Show" label is relatively minor, and this is certainly an interesting project to share!
There's a link to the rules/guidelines at the top of the "show" page:
https://news.ycombinator.com/showhn.html
Thanks for the explanation, won't make the same mistake twice, this was my first submission ever on HN.
Show HN's definitely have a prestige because we think it's the author's debut of the project, feel like we're helping out a community member, and expect them to be fielding answers in the comments.
Else everything is a Show HN. Like Show HN: Google's new privacy policy. ;)
Yep, that's definitely the case. It's not the end of the world, but, generally, don't use "Show HN" to highlight work that isn't yours.
Is this to add a scripting language to Go, like Lua is to Redis? It's a little unclear.
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).
using go then directly code in Go.
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.
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.
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?
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.
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?
looks like it is using the typescript API to compile the TS code at runtime
It seems to me what it means is that all builtin functions and objects have TS declarations from the start.
Finally, golang gets user accessible generics.
Lol "Status: segfaulty"
Mmm. Some may find that scary; I'd make it a link to an issue explaining/tracking what exactly causes it.
Roadmap suggests it has something to do with source maps?
Just realized the creator just scrambled the word "node" to have a new name.
Related: https://vimeo.com/56402326
At least he didn't call it "Done"
Can someone compare it with ts-node?
If I get it right, ts-node is just a transpiler, but deno runs "proper" ts?
Exactly what it seems like
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.
Importing URLs is how ES modules work afaik
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
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?
If anything this is only partially true: "Package plugin implements loading and symbol resolution of Go plugins."
https://golang.org/pkg/plugin
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?
Looks like it's aiming to be async/await compliant but dunno how that is implemented.
Ryan Dahl reserved the domain too, expect http://denojs.org to be the main website to this project!