Live data from Hacker News

Deno 1.0

deno.land

151–160 of 598 posts

Re: Deno 1.0

#151
post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…

See the thing about the sandbox is that it's only going to be effective for very simple programs.

If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs.

For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code from any url and run it immediately', means it's going to be much less secure than the already not-that-secure NPM ecosystem.

Re: Deno 1.0

#152
post #111

The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I…

Ever used Go? Not that different.

Go supports "vendor" folders for storing dependencies locally after initial download. That combined with Go Modules means you can handle everything locally and (I believe) reproducible.

Re: Deno 1.0

#153
post #127

Earlier quoted context omitted.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

To solve your issue, you would do exactly how you do your node deployments: download the deps in a folder in CI, then deploy the whole build.

Except that now, the download deps in CI step can fail if one of hundreds of websites for my hundreds of dependencies goes down. If the main NPM repository goes down, I can switch to a mirror and all of my dependencies will be available again.

Re: Deno 1.0

#154
post #142

Earlier quoted context omitted.

> As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. Deno runs JavaScript faster than node: echo "console.log(1 + 2)" > not-ts.js time deno run not-ts.js 3 0.01s user 0.01s system 89% cpu 0.025 total time node not-ts.js 3 0.03s user 0.08s system 53% cpu 0.203 total > Since…

> Deno runs JavaScript faster than node Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.

Can't you just pass it a .js file and it will skip the TypeScript compiling completely?

Re: Deno 1.0

#155

> In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependen…

Is this different from how streams work in most other languages, e.g. Java, Go, Python?

Re: Deno 1.0

#156
post #151
post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…

See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…

Maybe this will develop into a standard of multi-process servers (real micro services you could say), where the permissions are only given to a slice of the application.

Re: Deno 1.0

#157
post #145
post #137

Earlier quoted context omitted.

In practice modules will be available from sources that will have similar reliability to npm: github.com, unpkg.com, cdn.pika.dev, jspm.io, etc.

it's better because there will be more choice.

Doesn't this mean more opportunities to inject malicious code?

Re: Deno 1.0

#158
post #132

Earlier quoted context omitted.

Sure do. I wonder if they have a checksum mechanism like browsers do? You can add an “integrity” attribute to script tags in the browser. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

It's not just about the integrity. The url may very well provide what they claim to provide, so checksums would match, but it's the direct downloading and running of remote code that is terrifying. This is pretty much like all the bash one-liners piping and executing a curl/wget download. I understand there are sandbox restrictions, but are the restrictions on a per dependency level, or on a program level? If they ar…

If you afraid of "direct" downloading and executing some of that code, then what do you think happen when you npm install/pip install a package? I'm very interested if you can expose a new attack vector that didn't exist with the previous solutions.

Re: Deno 1.0

#159

Earlier quoted context omitted.

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.

I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified. The default in Deno is questionable choice. Just don't fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.

Using a universally unique identifier like a URL is a good idea: this way, https://foo.com/foo and https://bar.com/foo are distinct and anyone who can register their own name gets a namespace, without relying on yet another centralized map of names->resources.

After all, the whole point of a URL is that it unambiguously identifies resources in a system-independent way.

Re: Deno 1.0

#160
post #107

Earlier quoted context omitted.

You'll like https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript

Zero processing is a little generous, for things like like ES Module support (and interop), ts-node can be a struggle to get going.

As in .mjs files? Personally, I just want to import my own .js / .ts files and external npm packages which works well - https://github.com/gunn/covid-19-scripts/blob/023579e1cf/get...

The catch for me is that it's probably not suitable for a sever in production as mentioned elsewhere in this thread.

Post reply on HN