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

Deno 1.33: Deno 2 is coming

deno.com

Post reply on HN
Print view View original

121–127 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#121

Post by veidr »

LunaSea wrote: post #116
veidr wrote: post #100

Earlier quoted context omitted.

Wild take, but agree with your first sentence. 1.) it was never a language 2.) indisputably better security any time you take advantage of any of the features to disable reading of environment variables, using network, reading files, etc.

I see close to no case where you would not enable all access rights

Well they might not be your use cases, but surely you can imagine them, right?

A build tool, that reads input files and writes output files, and nothing else.

A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc.

A serverless function that doesn't need anything but networking.

Even when you need to allow whatever you're building to read the filesystem, just specifying which files/folders can be read is in an of itself a huge win.

Thinking on it a little more, I wonder what kind of gigantic monolith use cases are there that need to read/write completely arbitrary filesystem locations, and need to spawn subprocesses that can't be known ahead of time, and need to do networking, and need to read arbitrary environment variables that can't be specified ahead of time, and also need to load dynamic libraries, and also need that other permission I'm forgetting?

I mean, I am sure there are some, but that certainly isn't the default I'd choose.

Re: Deno 1.33: Deno 2 is coming

#122

Post by veidr »

conaclos wrote: post #61

Something that still stop me from using Deno is the incompatibility between Deno and other tooling regarding the import of TypeScript files. Namely, it is not possible to import a `.ts` file via a `.js` import [0]. [0] https://github.com/denoland/deno/discussions/18293

I know this doesn't directly address your specific scenario, with the '.js' import. But there is a similar situation that got a lot better with TypeScript 5.

For a long time I was annoyed by the similar problem of Deno's requirement for fully-specified import paths like 'foo/bar.ts' making our Deno code not easily interoperable with our "plain-ass TypeScript" code.

We have an Nx monorepo with a large amount of "library" code, which is really just TypeScript code that uses standard TypeScript path aliases[1]. This code is used by various teams for various things, like Node programs, Svelte/Angular/FrameworkOfTheWeek apps, local utilities and built tooling, etc).

However, until recently, none of these libs worked with Deno, because internally they had to import things like 'foo/bar' and not 'foo/bar.ts'. Changing the imports to 'foo/bar.ts' would make them work in Deno, but break them for everything else.

But TypeScript 5 really changed that with the addition of a new config option (discussed here recently[2]):

    "compilerOptions": {
        "allowImportingTsExtensions": true,
This lets me take a plain-ass TypeScript Nx monorepo library, and add it to my import_map.json, and use it from Deno code as well. (Nx recently released a new plugin to help with this.)

It's still not ideal, because you have to convert all the files to start importing and exporting using the ".ts" extension, and there are probably edge cases where it breaks something. However, I have been using it since the TypeScript 5 betas and I have not hit any problems yet. (Would be very curious to hear any problems other people have had, though.)

[1]: the entries in the "paths" section of tsconfig.json, which let you map your own import names to filesystem locations, so you can

    import { Hoge } from '@acme/hoge';
instead of:

    import { Hoge } from '../../../../libs/util/hoge/src/index.ts';
[2]: Previous discussion: https://news.ycombinator.com/item?id=35185069#35186448

Re: Deno 1.33: Deno 2 is coming

#123

Post by presentation »

qazxcvbnm wrote: post #78
presentation wrote: post #40

Earlier quoted context omitted.

The only true benefit I’m seeing as a potential Deno user is the faster startup time to reduce cold boots in a serverless setting - everything else is more in the category of “nice to haves” like ease of setup (I’m used to the workflows with Node so while it’s obtuse it’s something I know and is well documented on the web) and a tighter security model (I haven’t personally ran into any issues with this in Node but ca…

I was unaware of information on superior startup time for Deno and couldn't find references from a quick search. Would you be able to provide more information? Snapshots having landed in Node ( https://nodejs.org/en/blog/release/v18.8.0 ), is Deno still superior here?

Maybe I’m thinking more of Deno Deploy but they claim sub 400ms cold starts/40ms warm starts so yeah, pretty fast. Only other option I’ve seen that ballpark is with Cloudflare Workers.

Re: Deno 1.33: Deno 2 is coming

#124

Post by LunaSea »

veidr wrote: post #121
LunaSea wrote: post #116

Earlier quoted context omitted.

I see close to no case where you would not enable all access rights

Well they might not be your use cases, but surely you can imagine them, right? A build tool, that reads input files and writes output files, and nothing else. A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc. A serverless function that doesn't need anything but networking. Even when you need to allow whate…

> A build tool, that reads input files and writes output files, and nothing else.

If it wants to upload artefacts to a CDN it will also require network access.

> A CLI that interacts with the bug tracker, and needs to read the environment variables and do networking, but doesn't need to read the filesystem, launch subprocesses, etc.

Chances are the CLI needs to read ENV variables to authenticate or a configuration file and maybe even subprocesses to setup parallel processing.

> A serverless function that doesn't need anything but networking.

A serverless function will probably read environment variables as well or access a package.json file to read some context about the name of the package and it's version.

My point is that most programs will require all access enabled.

Re: Deno 1.33: Deno 2 is coming

#125

Post by veidr »

LunaSea wrote: post #124
veidr wrote: post #121

Earlier quoted context omitted.

Well they might not be your use cases, but surely you can imagine them, right? A build tool, that reads input files and writes output files, and nothing else. A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc. A serverless function that doesn't need anything but networking. Even when you need to allow whate…

> A build tool, that reads input files and writes output files, and nothing else. If it wants to upload artefacts to a CDN it will also require network access. > A CLI that interacts with the bug tracker, and needs to read the environment variables and do networking, but doesn't need to read the filesystem, launch subprocesses, etc. Chances are the CLI needs to read ENV variables to authenticate or a configuration fi…

I know that's your point, but I don't understand why you think that.

Even with your own theoretical additions to what the programs above need, none of the programs above actually need "all" access enabled.

And even when you do need to allow environment variables, subprocesses, and filesystem access, you can specify which ones. E.g. this program can read this specific package.json file and no other files. Or these three specific environment variables, and no others.

Which is still significantly different than "all".

Re: Deno 1.33: Deno 2 is coming

#127

Post by a1371 »

Sheepsteak wrote: post #60
a1371 wrote: post #23

Deno's major adoption point can be it's native typescript support but without an easy way to bring an npm package into it, developing its community will be tough. So I can totally see why they are ployfilling `node:crypto` since many cloud SDKs are using those in their packages.

You can import npm packages now. They added it a few release ago. https://deno.com/manual/node

The polyfills are not complete yet as this update points out
Post reply on HN