The Deno Company • Hacker News Board

Re: The Deno Company

#441

Post by FunnyLookinHat » Sat, Apr 03, 2021, 2:19 AM UTC

speedgoose wrote: post #396

FunnyLookinHat wrote: post #40

Earlier quoted context omitted.

The built-in Typescript support is amazing, but the selling feature for me was the ability to generate static binaries. Shipping is much easier when your built process can produce a single output!

A NodeJS Docker container is a few lines. I agree Deno's single binary is a nice feature but it's not very interesting for everyone.

A docker container works for services - but CLI tools are more easily shipped as binaries.

It certainly isn't that interesting for everyone, but for a subset of users it's great!

Re: The Deno Company

#442

Post by spion » Sat, Apr 03, 2021, 2:01 PM UTC

prussian wrote: post #440

spion wrote: post #104

Earlier quoted context omitted.

do you really want to keep util.promisifying everything? I know I don't. Streams (and event emitters, and the ecosystem bits that rely on them) still haven't fully caught up with promises either, e.g. async iterators and generators are still quite awkward

late reply. I've sort of experimented with async iterators and using pipeline() to pipe them together and it seems to work out for the most part; not sure what is awkward about them, I mean consume with an async iter on the source passed as an arg and you can throw at any time to kill it with an error. In fact I find the new async generator transforms easier and more ergonomic. in terms of event emitters. I can just…

Compare with the Dart stream API: https://api.dart.dev/stable/2.12.2/dart-async/Stream-class.h...

Re: The Deno Company

#443

Post by ignoramous » Sat, Apr 03, 2021, 4:51 PM UTC

kentonv wrote: post #435

ignoramous wrote: post #412

Earlier quoted context omitted.

> Lambda uses containers vs. cloudflare workers use v8 isolates. v8 Isolates are much much faster and more secure for serverless functions. You're right that v8 Isolates are blazing fast, but Lambda runs functions in a microvm spawn by Firecracker [0], which is likely to be more, not less, secure than Isolates [1]. [0] https://github.com/firecracker-microvm/firecracker/ [1] https://fly.io/blog/sandboxing-and-workload…

> Firecracker [0], likely to be more, not less, secure than Isolates [1] This is debatable. It's true that V8 is a much larger attack surface than Firecracker, therefore likely to have more security bugs than Firecracker itself. However, Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and ver…

Thanks Kenton.

> Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs...

I see your point. I mean, Google wouldn't put as much effort as they are on gVisor if KVMs were the best possible answer.

Re: The Deno Company

#444

Post by kentonv » Sat, Apr 03, 2021, 9:31 PM UTC

ignoramous wrote: post #443

kentonv wrote: post #435

Earlier quoted context omitted.

> Firecracker [0], likely to be more, not less, secure than Isolates [1] This is debatable. It's true that V8 is a much larger attack surface than Firecracker, therefore likely to have more security bugs than Firecracker itself. However, Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and ver…

Thanks Kenton. > Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs... I see your point. I mean, Google wouldn't put as much effort as they are on gVisor if KVMs were the best possible answer.

To be fair, gVisor also runs native code directly on hardware. Any modern VM-based system is still depending on the CPU to enforce boundaries. A big CPU bug could ruin that at any time. (Spectre has been pretty bad, but not quite a showstopper...)

Re: The Deno Company

#445

Post by dmitryminkovsky » Mon, Apr 05, 2021, 1:08 AM UTC

gervwyk wrote: post #359

dmitryminkovsky wrote: post #338

Earlier quoted context omitted.

> Is NPM really keeping you safe? I wish there was something like Docker Hub's automated builds in the Node world because the way NPM works right now, what comes from NPM is an unknown. The only thing you know is if you download a specific version once, you'll always get that same version again, unless it's invalidated. Otherwise, whatever the package author wants to upload and include, that's what you get and you ca…

THIS! I cannot believe that these is still no auto hash validator thing between git and npm. Feels like npm should force a commit containing hash for the current version on every publish or something. How can we make this happen?

It would have to be some kind of integrated CI build system thing that builds the product in a container. Seems like they have no incentive to offer that given that they totally own JS packages.

Re: The Deno Company

#446

Post by Griffinsauce » Mon, Apr 12, 2021, 1:45 PM UTC

zastrowm wrote: post #280

tannhaeuser wrote: post #209

Earlier quoted context omitted.

How is that different from Node.js which also runs in a single process? Or does Deno create per-request processes (or v8 "isolates" etc) like CGI does?

I think the point was that it's not different from Node.js - and thus not much of a benefit. If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.

Yes, this was my point. It's only trivially better in practice since you'll have to open all the doors nearly all the time.

We have so many dependencies that really only need to work in-memory and have zero IO needs. That part is not solved in Deno at all.