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