Finally, golang gets user accessible generics.
Deno, a secure TypeScript runtime using V8 and Go
11–20 of 42 posts
Re: Deno, a secure TypeScript runtime using V8 and Go
#12Worth 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.
Re: Deno, a secure TypeScript runtime using V8 and Go
#13Lol "Status: segfaulty"
Re: Deno, a secure TypeScript runtime using V8 and Go
#14Just realized the creator just scrambled the word "node" to have a new name.
Re: Deno, a secure TypeScript runtime using V8 and Go
#15Just realized the creator just scrambled the word "node" to have a new name.
[deleted]
Re: Deno, a secure TypeScript runtime using V8 and Go
#16Worth 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.
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.
Re: Deno, a secure TypeScript runtime using V8 and Go
#17Worth 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.
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.
Re: Deno, a secure TypeScript runtime using V8 and Go
#18What 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 unprivileg…
> 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.
Re: Deno, a secure TypeScript runtime using V8 and Go
#19Earlier quoted context omitted.
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
> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.
Re: Deno, a secure TypeScript runtime using V8 and Go
#20What 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 unprivileg…
> 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 eliminat…
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?