31–40 of 42 posts
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.
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."
Is this to add a scripting language to Go, like Lua is to Redis? It's a little unclear.
Earlier quoted context omitted.
> 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?
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?
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
Earlier 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.
Can someone compare it with ts-node? If I get it right, ts-node is just a transpiler, but deno runs "proper" ts?
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?