Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the Hell Is a Deno?

breadth.substack.com

Post reply on HN
Print view View original

111–120 of 151 posts

Re: What the Hell Is a Deno?

#111

Post by hombre_fatal »

theshrike79 wrote: post #80
rhlsthrm wrote: post #71

Earlier quoted context omitted.

As someone with most of my coding experience in JS/TS, what would you say is a good alternative to explore?

Go with goroutines and channels is a nice way to handle concurrency. At least it was the one that was easiest for me to wrap my head around and actually improved the performance of my code without weird race conditions or bugs.

Go concurrency is basically threads + the ability to choose between classic mutex synchronization (and all the problems with that like reentrancy bugs) or burn yourself in channel hell with deadlocks and buffer bloat.

Re: What the Hell Is a Deno?

#112

Post by hombre_fatal »

knome wrote: post #30
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.

I dislike javascript for much the reason you love it. Promises just mean having to manually build and manipulate cooperatively multitasking green-threaded call-stacks. It was a dirty necessity following the inability of the earlier callback patterns to manage the level of complexity people were attempting to express in the language.

Even Rust implemented async/await. It's one of the few nice ways to write asynchronous code.

People who think that it's "manual" only haven't yet discovered the trade-offs of what they think is their preferred solution. There is no free lunch here.

It's like sniping at people who chose different prongs of the CAP theorem while thinking you're somehow in a superior position.

Re: What the Hell Is a Deno?

#113

Post by brabel »

sktrdie wrote: post #110

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 }}}'

Just `import { foo } from 'https://graphql/'` is enough for that.

Re: What the Hell Is a Deno?

#114

Post by hombre_fatal »

jfkebwjsbx wrote: post #95
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.

Why do you need async for "anything networked"? Genuinely asking. There are many ways of doing I/O, but nowadays everyone seems to do everything async without giving it a second thought.

It's more about the concurrency abstractions available. And half the joy of writing async code in JS is that it's single-threaded.

Doing many things at the same is inherent to doing networked stuff. How ergonomic that is going to be is one of the only real things that sets languages apart.

Re: What the Hell Is a Deno?

#115

Post by brabel »

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.

If you think async/await is the holy grail of networking, you're up for a surprise in the next few years.

The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...

This seems to me to obsolete async/await, quite honestly.

Re: What the Hell Is a Deno?

#116

Post by fanf2 »

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…

What deno wants is something like caja - https://en.m.wikipedia.org/wiki/Caja_project - object-capability security for JavaScript. Sadly I believe the caja project was not successful because it is very hard to avoid ambient authority in JS without becoming incompatible with everything.

Re: What the Hell Is a Deno?

#117

Post by hombre_fatal »

brabel wrote: post #115
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.

If you think async/await is the holy grail of networking, you're up for a surprise in the next few years. The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h... This seems to me to obsolete async/await, quite honestly.

Don't fall into the trap of thinking that just because you've found a blog post that could enumerate the downsides of something that the alternatives don't have the same trade-offs.

I've responded to that ancient blog post many times on HN by now. Since you must think that blog post is pretty good criticism of async/await, here's a little challenge for you: which language do you think doesn't have an equivalent of the "red vs blue" problem? :)

Re: What the Hell Is a Deno?

#118

Post by michaelcampbell »

brabel wrote: post #115
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.

If you think async/await is the holy grail of networking, you're up for a surprise in the next few years. The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h... This seems to me to obsolete async/await, quite honestly.

> If you think async/await is the holy grail of networking,

They wrote that it's better, not perfect.

Re: What the Hell Is a Deno?

#119

Post by JohnL4 »

hombre_fatal wrote: post #117
brabel wrote: post #115

Earlier quoted context omitted.

If you think async/await is the holy grail of networking, you're up for a surprise in the next few years. The problem with async/await: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... A solution proposed by none other than Java (available as an experimental feature in JDK 15): http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h... This seems to me to obsolete async/await, quite honestly.

Don't fall into the trap of thinking that just because you've found a blog post that could enumerate the downsides of something that the alternatives don't have the same trade-offs. I've responded to that ancient blog post many times on HN by now. Since you must think that blog post is pretty good criticism of async/await, here's a little challenge for you: which language do you think doesn't have an equivalent of th…

A link to one of your responses would be spiffy.

Re: What the Hell Is a Deno?

#120

Post by pacoverdi »

jessaustin wrote: post #55
CalmStorm wrote: post #18

Deno's sandbox security is somewhat similar to Mandatory Access Control (MAC) implemented by SELinux and AppArmor. But it looks like not as fine-grained as MAC. In the example: deno run --allow-net myWebserver.ts With SELinux, one can specify the port range and network interface that the application is allowed to access. It also provides audit log that can be examined by the admin. Maybe there is no need to reinvent…

Am I wrong in thinking that this example specifically does not protect against the threat posed immediately preceding it? As in, one is running a script that foolishly imports a nefarious package that uploads tasty environmental variables to an evil server, which it can do when network access is not controlled. Well, what if myWebserver.ts imports that package? A more fine-grained approach that limited network access…

That's my impression too (see my other comment).

Each package published to Deno could come with a set of declared permissions (similarly to Android apps).

When importing the package in a module, Deno should detect that permissions scoped at current module level are wider than what the package requires, and automatically narrow down the list of authorized calls.

This would probably be very costly. Suppose that I'm importing a function from lodash (that requires no permissions) and my module calls it repeatedly while also accessing the file system...

Post reply on HN