Deno 2.8 • Hacker News Board

Re: Deno 2.8

#191

Post by AgentME » Tue, May 26, 2026, 7:19 PM UTC

VerifiedReports wrote: post #151

AgentME wrote: post #110

Earlier quoted context omitted.

One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.) Also, if multiple dependencies…

Thanks. I use JSR and always pull in the latest, figuring that I'll lock it down when development is done.

Your deno.json/package.json should generally pin things to their major version (eg. "^3.1.4"). Your application's lockfile (deno.lock/package-lock.json) which is generated by default pins your dependencies and your sub-dependencies to exact versions.

Re: Deno 2.8

#192

Post by Sammi » Wed, May 27, 2026, 9:13 AM UTC

nine_k wrote: post #181

Sammi wrote: post #101

Earlier quoted context omitted.

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.

I see how this might seem like it would make Bun important to Anthropic, but there are just so many examples of companies losing interest in the technology that their product "runs on". It's just infrastructure to them. To the C-suite, infrastructure is fungible.

Re: Deno 2.8

#193

Post by vrighter » Mon, Jun 08, 2026, 7:53 AM UTC

AgentME wrote: post #190

vrighter wrote: post #164

Earlier quoted context omitted.

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.

but you can relatively easily sandbox anything you want and close all escape hatches. If you want to turn off the monkeypatching functionality, that's just a metatable or two away. I can and regularly disable monkeypatching on some of my libraries (especially where it interacts with c++ interop). JS now has proxy objects, but lua has been able to do this since way before

And also those stackful coroutines, would have made callback hell non-existent, and no async/await function coloring either (as long as you started one coroutine somewhere up the call stack.