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

Deno 2.8

deno.com

Post reply on HN
Print view View original

181–190 of 193 posts

Re: Deno 2.8

#181

Post by nine_k »

Sammi wrote: post #101
vmsp wrote: post #11

Earlier quoted context omitted.

That wasn't a value judgment on the acquisition. I was just pointing out that it made the project more sustainable.

That's a yes and no. Venture funded companies like Anthropic have a history of low follow through with peripheral projects (like Bun is for them). Of course they do - their responsibility is ultimately primarily to their investors - not to Bun. So the risk now is that Anthropic will can Bun whenever they just lose interest or feel it's just a drain that's not contributing directly to their bottom line. Node.js itself…

Bun is not peripheral, it's what Claude Code runs on.

Re: Deno 2.8

#182

Post by oblio »

stephbook wrote: post #158
MrJohz wrote: post #122

Earlier quoted context omitted.

I think the biggest issue with Deno is that it fixes real issues but in the wrong way. Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will c…

Use a .devcontainer and you're done in 10 seconds without any new runtime implementations.

I'm not sure how this solves lodash wanting network access.

Re: Deno 2.8

#183

Post by wpollock »

pjmlp wrote: post #149
wpollock wrote: post #128

Earlier quoted context omitted.

> Because "it doesn't exist". It's just a layer on top of js, ... C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C. There is nothing preventing TypeScript from becoming "native" in a similar way.

Typescript is only a linter, except for types annotations it is regular JS, quite different from C with Classes. If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.

> Typescript is only a linter...

I never thought of Typescript (TS) that way. I believe TS is a language addition that enabled smarter JavaScript linters; TS is not a linter program per se.

However, TS is more than that now. The extra annotations enable optimizing transpilers and even compilers (to WASM, for instance). This makes TS much more than just a better linter; I think of TS as a better language.

Re: Deno 2.8

#184

Post by sellmesoap »

tomjakubowski wrote: post #60
nailer wrote: post #51

Earlier quoted context omitted.

(thinking emoji) they could merge. Seriously, they're both Rust now. They share goals.

I doubt it would work out. The engineering cultures could not be any different.

I think different cultures can contribute to eachother, they don't have to hold hands. I'm sure open minded curious developers can look over the fence and appreciate the differences and adopt practical aspects of each other, maybe the time to stop and smell the roses is to poetic and altruistic. It's a JavaScript server/packager/framework drag race for pink slips!

Re: Deno 2.8

#185

Post by pjmlp »

wpollock wrote: post #183
pjmlp wrote: post #149

Earlier quoted context omitted.

Typescript is only a linter, except for types annotations it is regular JS, quite different from C with Classes. If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.

> Typescript is only a linter... I never thought of Typescript (TS) that way. I believe TS is a language addition that enabled smarter JavaScript linters; TS is not a linter program per se. However, TS is more than that now. The extra annotations enable optimizing transpilers and even compilers (to WASM, for instance). This makes TS much more than just a better linter; I think of TS as a better language.

Already covered by JSDoc, closure, and Babel before Typescript came to be.

Java IDEs were taking advantage of them for web development workflows, before VSCode came to be.

Also VSCode main architect is one of the Eclipse original architects.

Re: Deno 2.8

#186

Post by bartlomieju »

ddosmax556 wrote: post #83
dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

I can tell you my experience as a js package dev, last tried a few weeks ago. We're building an npm package that's supposed to run on both node.js, deno & bun & the web. This is an annoying to do for exactly two platforms: node.js, and deno. node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same st…

Thanks for feedback, I opened a PR to implement linking functionality that seems more familiar to npm's strategy: https://github.com/denoland/deno/pull/34359

Re: Deno 2.8

#187

Post by bartlomieju »

garganzol wrote: post #159
notnullorvoid wrote: post #120

A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second. The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting plat…

I somewhat agree with you. For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...

Bartek from the Deno team here. Thanks for the feedback. I assure you this is not a short-sighted change. This has been a problem since before Deno 1.0. We resorted to hacks like different set of globals for user code and different for code inside node_modules/ directory. It was a maintenance headache, made global lookups super slow and was really hard to explain to users. While Web "setTimeout" might have been nice in the beginning the fact that it required additional APIs like "Deno.unrefTimer" made it worse than Node's setTimeout.

Re: Deno 2.8

#188

Post by bartlomieju »

notnullorvoid wrote: post #120

A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second. The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting plat…

Bartek from the Deno team here. Thanks for the feedback, I understand your frustration.

> The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default.

Since a few versions ago, Deno now has some of Node.js APIs included by default (eg. process or Buffer). It's really more of a bug fix to make type-checking work properly.

While it's not ideal, you can still decide which types you want included by default with `compilerOptions.types`. `["deno.ns", "web"]` should give you what you're looking for.

Re: Deno 2.8

#190

Post by AgentME »

vrighter wrote: post #164
AgentME wrote: post #117

Earlier quoted context omitted.

Javascript/Typescript as it is now isn't a great language for a real capability system because any code can monkey-patch global objects and use that to steal capability objects from elsewhere. JS code of different privilege levels needs to be run in separate realms at the very least. (Though there are proposals for things like frozen realms that try to make JS more suitable for capability systems.)

one more reason I would have preferred a world in which lua was used in js's place

Isn't Lua equally monkey-patchable? Both of the languages, along with Python and Ruby, represent nearly everything as mutable objects.
Post reply on HN