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

Deno 1.9

deno.com

Post reply on HN
Print view View original

241–245 of 245 posts

Re: Deno 1.9

#241

Post by pocketgrok »

oscargrouch wrote: post #225
tym0 wrote: post #196

Earlier quoted context omitted.

> Deno glue code around V8 is written in Rust. Maybe this is not the best way of putting it. They use Rust for all the system bits including networking, so it's not like they just wrote some JS to V8/C++ glue code in Rust.

Ok, but even if there's more Rust code in it, i think the expectations of the parent poster are unreal, as for safety, only if V8 VM were rewritten in Rust, and giving its a JIT VM sensitive portions of code would need to be in 'unsafe{}' anyway, so how much safer would it turn out to be even than? Anyway in security terms it will probably turn out negligible as the percentage of code in safe Rust are probably low co…

Ryan Dahl has talked about why he chose Rust at various times. The original prototype was actually written in Go but was ported to Rust to avoid garbage-collection issues. The real reason for these languages over C++ was more about maintainability than type safety or speed. Ryan seems to be pretty happy with Rust so far which is a good sign but doesn't mean that there are direct benefits to users.

Re: Deno 1.9

#242

Post by pocketgrok »

beaker52 wrote: post #180
kybernetikos wrote: post #175

Earlier quoted context omitted.

What I dislike is that you provide these permissions for the whole process. I'd like it to be more that you can constrain and pass the permissions down to libraries like capabilities.

I agree. I hear a lot made of Deno's "security" but process flags don't really make me feel much more secure when I've had to enable most of them anyway. At that point they just start getting in the way and giving me a false sense of security.

My understanding is that the current security flags model isn't really meant to be the final solution. They wanted to ensure that the browser security model isn't simply dropped like it is in Node, but to improve it further they'll probably need outside help.

Re: Deno 1.9

#243

Post by tracker1 »

hayd wrote: post #73
paxys wrote: post #55

Earlier quoted context omitted.

When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention). Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold fo…

There's the web APIs which are tested against https://github.com/web-platform-tests/wpt (albeit without full coverage), and there is ffi/plugins - for deno specific things like readFile. I don't know the history of Node... but why would there need to be a diversion?

Because CJS's "require" is synchronous and was never implemented IN the browser... Deno is close to standards compliant syntax, so much closer to what's in the browser (TypeScript being a super-set). You can use most JS written for Deno in the browser without having to re-write or create odd shims.

Re: Deno 1.9

#244

Post by tkzed49 »

sjy wrote: post #63
tkzed49 wrote: post #58

Earlier quoted context omitted.

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?

Deno uses ES6 modules, which are supported by modern browsers. There’s no node_modules. https://deno.land/manual/examples/import_export

Yeah, I guess if you don't use typescript? But isn't that a lot of the appeal of deno? The browser can't import a TS module.

Re: Deno 1.9

#245

Post by mssundaram »

folkrav wrote: post #235
tengbretson wrote: post #210

Earlier quoted context omitted.

> Hmm, what did I miss, why do people hate them exactly? They operate in a weird gray-zone between being just compile-time types vs. an actual readonly object in the runtime. I don't think I've seen a use case for them yet that wouldn't have been better accomplished with a union type of string literals and using const string literals in the code.

Say all you need is a fixed set of strings that get reused everywhere. What is better accomplished by defining a union type AND consts literals rather vs creating a single string-based enum and using that everywhere? I feel like I'm misunderstanding...

You don't even need the const literals.

    type Color = "red" | "blue" | "green";
Post reply on HN