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

Deno 1.0

deno.land

Post reply on HN
Print view View original

411–420 of 598 posts

Re: Deno 1.0

#411

Post by oblio »

didip wrote: post #332

I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly. Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.

> It is easy to get up-and-running quickly.

Almost all successful, mainstream, techs are like that. From a purely technical perspective, they are awful (or where awful at launch), they were just adopted because they were easy to use. When I say awful, I mean for professional use in high impact environments: financial, healthcare, automotive, etc.

Examples: VB/VBA, Javascript, PHP, MySQL, Mongo, Docker, Node.

Few people would argue that except for ease of use and ubiquity, any of these techs were superior to their competitors at launch or even a few years after.

After a while what happens is that these techs become entrenched and more serious devs have to dig in and they generally make these techs bearable. See Javascript before V8 and after, as an example.

A big chunk of the HN crowd is high powered professional developers, people working for FAANGs and startups with interesting domains. It's only normal they criticize what they consider half-baked tech.

Re: Deno 1.0

#412

Post by regularfry »

feihcsim wrote: post #364
seleniumBubbles wrote: post #5

Congratulations on the 1.0 release! I've been using Deno as my primary "hacking" runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It's even easier than ts-node, which I primarily used previously.) I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support.…

i wonder if it's conceivable to ever write typescript in a REPL

There are both ocaml and haskell repls, so it can be done with languages whose type systems are the focus. Not sure if there's anything specific about typescript that would make it hard, though.

Re: Deno 1.0

#413

Post by tuukkah »

regularfry wrote: post #405
half-kh-hacker wrote: post #268

Earlier quoted context omitted.

Both the network and disk access permissions are granular, which means you can allow-write only to your logs folder, and allow net access only to your DB's address.

So it's reimplemented chmod and iptables?

Typically, chmod and iptables are not used to restrict applications. Applications are restricted by virtual machines, containers, sandboxes, AppArmor profiles, SELinux policies…

Re: Deno 1.0

#414

Post by inimino »

giorgioz wrote: post #408

I have two questions: 1) How to port a node package to deno? 2) How to keep both a node and deno packages in the same repo? Clearly without packages we are not going to use deno. Also I don't want to switch from well-proven packages like express/koa to an new unknown http server just because it supports deno.

Deno is a new thing. It's not node, and not having the entire npm ecosystem already around it can be seen as a blessing.

By the way a new http server doesn't "support" deno any more than Express "supports" node -- it's the other way around.

Re: Deno 1.0

#415

Post by torb-xyz »

nojvek wrote: post #393

> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…

There already exists and experimental compiler that takes a subset of TypeScript and compiles it to native[1]. It might be able to target wasm instead of asm.

Also: If I'm not entirely mistaken Microsoft initially planned to have a TypeScript-specific interpreter in Explorer. This also might indicate that something like that could be possible.

1: https://www.microsoft.com/en-us/research/publication/static-...

Re: Deno 1.0

#416

Post by yoz-y »

danShumway wrote: post #347
bgdam wrote: post #151

Earlier quoted context omitted.

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…

> That combined with the 'download random code from any url What protection does NPM actually give you? Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable ins…

> What protection does NPM actually give you?

Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well.

I think this could be fixed quite easily if one could add a hash and a size after the url, to force a check.

Re: Deno 1.0

#417

Post by DarkWiiPlayer »

ecares wrote: post #402

Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo REF: https://github.com/denoland/deno/issues/1063

That's really just a HTTP problem though, isn't it? If you use HTTP, you're exposing yourself to MITM attacks; that's on you.

Is there any possible way to face this vulnerability without either 1) linking to a resource over HTTP or 2) loading a resource from someone else who linked to another resource over HTTP?

Case one is the devs fault for doing it; case two is also the devs fault for not even checking their dependancies.

As infrastructure grows, there will be tools that either extend the environment to block/log HTTP stuff, or catch HTTP URIs in static analysis. Both of these, specially in combination, would be more than enough.

Re: Deno 1.0

#418

Post by torb-xyz »

First-class TypeScript support is the thing that excites me the most about this. It's so annoying when you want to navigate TypeScript code from a dependency in Node and it kicks you to a TypeScript-definition file instead of the actual TypeScript source.

Re: Deno 1.0

#419

Post by ecares »

DarkWiiPlayer wrote: post #417
ecares wrote: post #402

Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo REF: https://github.com/denoland/deno/issues/1063

That's really just a HTTP problem though, isn't it? If you use HTTP, you're exposing yourself to MITM attacks; that's on you. Is there any possible way to face this vulnerability without either 1) linking to a resource over HTTP or 2) loading a resource from someone else who linked to another resource over HTTP? Case one is the devs fault for doing it; case two is also the devs fault for not even checking their depen…

well, most of Deno marketing is that it is safe by default. In 2020, not enforcing a secure protocol to share source code is a no go at all. I really don't get your point here defending something that has not made any sence since the end of last decade.

Knowingly leaving this kind of things in the codebase totally invalidate Deno being secure. There is not possible discussion in 2020 about https not having to be enforced. People thinking otherwise should not be allowed near a computer for their own good.

Re: Deno 1.0

#420

Post by baxuz »

nojvek wrote: post #393

> TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be com…

I see the sass / node-sass fiasco all over again...
Post reply on HN