What the Hell Is a Deno? • Hacker News Board

Re: What the Hell Is a Deno?

#101

Post by pacoverdi » Thu, Jun 04, 2020, 9:30 AM UTC

SCdF wrote: post #91

pacoverdi wrote: post #79

I assume that permissions are given at application level, not at module/import level? This means that if I write an application that requires filesystem access and has external dependencies, I'm essentially giving them access to the filesystem even if they don't need it. These dependencies could silently check whether they have permissions and do something fishy only if that is the case. It would be nice to be able t…

I haven't looked into it, but TFA suggests you can do it call by call.

Well I'm not sure. The doc says:

Access to security sensitive areas or functions requires the use of permissions to be granted to a deno process on the command line. [1]

The only other mention of permissions in documentation is that a program may query or revoke permissions.

[1] https://deno.land/manual/getting_started/permissions [2] https://deno.land/manual/examples/permissions

EDIT: formatting

Re: What the Hell Is a Deno?

#102

Post by Pozzuh » Thu, Jun 04, 2020, 9:37 AM UTC

memexy wrote: post #59

etaioinshrdlu wrote: post #43

Earlier quoted context omitted.

Yes... it would actually be quiet amazing to have different libraries in different sandboxes with defined communication channels. The browser actually does something quite a bit like this with iframes. Iframes are sandboxed and can only communicate through postMessage. There's more to it but at a simple level it looks like this. Chrome nowadays even runs iframes in a separate process! Finally... https://www.chromium.…

You could implement this by fine grained imports and subprocess execution. Node.js actually has a very nice sub-process communication API: https://nodejs.org/api/child_process.html#child_process_subp... . At some point I remember writing some gpg wrappers with Node.js and I remember the subprocess API being one of the more pleasant ones to work with. In the case of more stringent Deno process sandboxing, the parent p…

Deno uses the web standard Worker API to implement sub processes. They are also working on fine-grained permissions for these workers [1].

[1] https://github.com/denoland/deno/issues/4867

Re: What the Hell Is a Deno?

#103

Post by marcodave » Thu, Jun 04, 2020, 9:59 AM UTC

Some random comments: - good to see native TS support

- Would be nice to see a builtin maven/gradle-like standard build system, which IMHO not having it in node.js was a major let down for me. Sure, you have gulp/grunt, but having to write repetitive code (which can be buggy!) for running a compiler/test/packager? With another set of plugins? just give me some standard tool and let me call the equivalent of "mvn package", which will compile/test/package my application with sane defaults.

- the dependencies-as-URL is going to be hit hard as soon as some big fish corporation wants to use Deno for some in-house projects. What if those corps disallow calling https://deno.land/my/dep and pretend to use internal repo? now all 3rd party dependencies won't work unless manually modified to use the internal corp repo.

- I predict that the --allow-this --allow-that will evolve in a SecurityManager-like complexity, that only the early enthusiasts will understand, and the rest will simply put the equivalent of "--allow-all" and let the ops deal with security issues

Re: What the Hell Is a Deno?

#104

Post by azangru » Thu, Jun 04, 2020, 10:12 AM UTC

hombre_fatal wrote: post #24

fearingreprisal wrote: post #22

For me this is a case of "too little, too late". I've been burned too much over the years by the Node ecosystem to risk investing any further interest in it now, even if it has marginally improved. I have worked extensively with Typescript, which I consider to be the minimum viable solution within the Node ecosystem. Typescript shouldn't even be seen as a 'nice-to-have. It should be seen as a required remedy for some…

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

> Async/await + the ubiquitous Promise

There's a legitimate concern about async-awaits — they don't have an inbuilt cancellation mechanism. May not be a big thing for the server; but definitely a big thing for the client.

See, for example: https://twitter.com/getify/status/1171820070538022914

Re: What the Hell Is a Deno?

#105

Post by addicted » Thu, Jun 04, 2020, 10:13 AM UTC

jfkebwjsbx wrote: post #88

bryanrasmussen wrote: post #48

Earlier quoted context omitted.

the parent said something about problems being solved if there was a standard library, and if perhaps there were a standard library people would be willing to write more code instead of just adding another dependency. I believe these points dependencies are carefully considered by users dependencies try to be dependency-free themselves to assist with the previous point dependencies solve important domain problems, th…

A good standard library helps, no doubt. However, it is not required. One of the languages mentioned was C++. That language has a tiny standard lib in comparison to Java. So it is mainly a "cultural" thing and how projects are structured and reviewed.

C++ had a tiny standard library.

That’s why Boost exists (although much of its functionality has been subsumed into the std lib now).

Re: What the Hell Is a Deno?

#106

Post by hombre_fatal » Thu, Jun 04, 2020, 10:20 AM UTC

thelazydogsback wrote: post #28

hombre_fatal wrote: post #24

Earlier quoted context omitted.

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node…

I'm not being unfair when I enumerate the most popular languages for comparison. When people crap on Javascript, they presumably prefer another language. And C#/Kotlin aren't exactly the top picks.

Kotlin has BYOB coroutines which are hard to work with. People don't use them. Going with the C# approach where async behavior looks sync was a bad move. I predict Kotlin's coroutines will never be a centerpiece abstraction just like how people don't really use Go's channels (people in practice just go back to Mutexes).

I mean, try it. Write the equivalent to this in Kotlin:

    // get background work started now
    const background = promise()
    
    // crawl some urls concurrently as well, just 4 at a time
    const crawl = Promise.map(urls, crawl, { concurrency: 4 })

    // while that's going on, we have some work that
    // we must get done.
    for (const task of tasks) {
      await worker(task)
    }

    // worker's done, now we can wait on 
    // the crawler and background work.
    const [a, b] = await Promise.all([
      crawl.then(processResults),
      background
    ])

CSP never caught on because after you have more than one channel as a central bus (the toy architecture), you immediately descend into channel hell. In-channels, out-channels, channels over channels. Back to using pencil and paper and scouring your code to decode the classic buffer bloat problem.

A single-threaded event loop with a central promise abstraction is a great way to write networked code.

Btw, I use Kotlin in a large JVM project and I'm stuck with the horror of https://docs.oracle.com/javase/8/docs/api/java/util/concurre.... That's more likely what you'll be doing day to day with Kotlin, not playing with its toy coroutines.

Re: What the Hell Is a Deno?

#107

Post by ldeangelis » Thu, Jun 04, 2020, 10:33 AM UTC

One point that was not mentioned: Deno is distributed as a single binary. Combined with the security options, I think it's a great feature for small scripts in an enterprise context.

Re: What the Hell Is a Deno?

#108

Post by hombre_fatal » Thu, Jun 04, 2020, 10:40 AM UTC

azangru wrote: post #104

hombre_fatal wrote: post #24

Earlier quoted context omitted.

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

> Async/await + the ubiquitous Promise There's a legitimate concern about async-awaits — they don't have an inbuilt cancellation mechanism. May not be a big thing for the server; but definitely a big thing for the client. See, for example: https://twitter.com/getify/status/1171820070538022914

Free cancelation has been a pipedream since day one of computer science.

We don't want it so badly that we want to pass around poison channels or cancelation tokens. People don't even bother threading cancelation contexts in Go because it's annoying and you still have to write disposal logic for anything worth canceling (which usually isn't possible anyways -- e.g. can't undo that database query that's in flight).

There are cute things you can do with generators in the UI where cancelation cascades make a lot of sense, but notice how nobody actually cares enough to use redux-saga nor this guy's library.

Re: What the Hell Is a Deno?

#109

Post by adev_ » Thu, Jun 04, 2020, 10:46 AM UTC

azangru wrote: post #104

hombre_fatal wrote: post #24

Earlier quoted context omitted.

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

> Async/await + the ubiquitous Promise There's a legitimate concern about async-awaits — they don't have an inbuilt cancellation mechanism. May not be a big thing for the server; but definitely a big thing for the client. See, for example: https://twitter.com/getify/status/1171820070538022914

> There's a legitimate concern about async-awaits — they don't have an inbuilt cancellation mechanism. May not be a big thing for the server;

They are definitively a big thing for the server.

The lack of cancellation mechanism and pre-emption + single threaded nature are the main reasons why the P95 latency of Nodejs App tend to get horrible under load.

Re: What the Hell Is a Deno?

#110

Post by sktrdie » Thu, Jun 04, 2020, 10:55 AM UTC

I love how Browsers & Deno have shown how we can do dependency management using urls containing code (ESM). This is a huge step forward.

This makes me think, is file-based code-split strategy enough?

What if we'd put code (not data) behind GraphQL and request only the actual piece of code we need to use?

import { foo } from 'https://graphql/{ give: { me: { foo }}}'