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

Deno 2.9

deno.com

Post reply on HN
Print view View original

11–20 of 63 posts

Re: Deno 2.9

#11

Post by dismalaf »

Tiberium wrote: post #2

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one). For e…

Deno went downhill as soon as they introduced Node compatibility. It promised a better way of doing things, then stooped back down to Node fuckery.

Re: Deno 2.9

#12

Post by [deleted] »

MoonWalk wrote: post #5
Tiberium wrote: post #2

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one). For e…

Well if Node compatibility is your big deal then yeah, why not just use it? I started a new project on Deno to avoid the NPM mess. Node compatibility was a distraction for the product. I'm tired of everything depending on Node. Assuming that everybody uses it is lazy.

[deleted]

Re: Deno 2.9

#13

Post by bartlomieju »

Tiberium wrote: post #2

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one). For e…

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208

Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from Node.js codebase, we just don't catch everything. We're constantly working on improving the situation and I'm sorry you hit a problem. I can assure you that we are fixing all Node compat bugs as quickly as possible.

Re: Deno 2.9

#14

Post by conartist6 »

bartlomieju wrote: post #13
Tiberium wrote: post #2

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one). For e…

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208 Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from N…

Of course the AI is not at fault, you were responsible as an engineer and you abdicated your responsibility

Re: Deno 2.9

#15

Post by pixel_popping »

bartlomieju wrote: post #10
catapart wrote: post #7

EDIT: This was my fault. My machine did not take the update well and I did not confirm that the update worked before complaining about it (burned once before, so I was biased). After testing on a secondary machine and then forcing the upgrade on the initial machine, both machines ran both projects just fine. Great job by the devs! Sorry for the misinformation here. Original message: -------------------------------- I…

Gee, sorry to hear that. It's Bartek from the Deno team here. This is really a whack-a-mole. We currently present the latest stable Node.js version (26.3.0) so the error is not correct - I bet it's probing for something stupid like no of arguments a certain function supports. Is your project open source so I can take a look myself?

You can have AI do way more automated testing in a loop, let cheap models run 24/7 so all edge cases can be found over time by pulling random repos, you must make sure the agent is entirely autonomous, ask another agent to make a list (also in a loop so it keeps appending to it) and another agent that try to fulfill "run it with Deno".

Re: Deno 2.9

#16

Post by re-thc »

bartlomieju wrote: post #13
Tiberium wrote: post #2

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one). For e…

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208 Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from N…

> Rewrite the entire node:http stack to use llhttp (Node.js's HTTP parser)

Can we please not turn Deno into junk? If you do the above -- what's the point of Deno?

Once you bolt everything on like that you might as well just use Node.

Deno started off with its own tools. Bun has managed a good balance between compatibility and its own thing (the recent moves aside) without resorting to these tactics...

Re: Deno 2.9

#17

Post by shimman »

Deno is a great example of how taking VC investments tanks the viability of an open source project. They keep focusing on money driving projects for an extremely small + fractured community (let's be honest here, whose only customers who are likely other VC holdings), oh and having continuous major layoffs does not signal good leadership qualities.

Ryan Dahl is assuredly a poor steward of open source software if these are the results. Node is popular because of the massive, inclusive community behind it; not because of a few rock star individuals, but for the VC mindset it's much easier to control an individual programmer than a community of them.

Only wonders are what other communities VC will try to rat fuck next, how fast do we think Evan You will speed run this exact same arc (which has already happened a dozen times in lived memory), and why does Bryan Cantrill feel like the only smart tech executive that doesn't fall into these traps?

Re: Deno 2.9

#18

Post by bartlomieju »

re-thc wrote: post #16
bartlomieju wrote: post #13

Earlier quoted context omitted.

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208 Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from N…

> Rewrite the entire node:http stack to use llhttp (Node.js's HTTP parser) Can we please not turn Deno into junk? If you do the above -- what's the point of Deno? Once you bolt everything on like that you might as well just use Node. Deno started off with its own tools. Bun has managed a good balance between compatibility and its own thing (the recent moves aside) without resorting to these tactics...

We tried to build `node:http` on top of Rust libraries (like Hyper) but we failed for a couple years. So earlier this year we decided to make it compatible (by using llhttp to have very high coverage - at the moment 88% compatibility for node:http module) and then focus on improving performance and slowly chipping away llhttp parts while keeping compatibility.

Re: Deno 2.9

#19

Post by someguyiguess »

pixel_popping wrote: post #15
bartlomieju wrote: post #10

Earlier quoted context omitted.

Gee, sorry to hear that. It's Bartek from the Deno team here. This is really a whack-a-mole. We currently present the latest stable Node.js version (26.3.0) so the error is not correct - I bet it's probing for something stupid like no of arguments a certain function supports. Is your project open source so I can take a look myself?

You can have AI do way more automated testing in a loop, let cheap models run 24/7 so all edge cases can be found over time by pulling random repos, you must make sure the agent is entirely autonomous, ask another agent to make a list (also in a loop so it keeps appending to it) and another agent that try to fulfill "run it with Deno".

You're getting downvoted because "AI bad" but this is actually a good idea.

Re: Deno 2.9

#20

Post by bartlomieju »

conartist6 wrote: post #14
bartlomieju wrote: post #13

Earlier quoted context omitted.

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208 Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from N…

Of course the AI is not at fault, you were responsible as an engineer and you abdicated your responsibility

Sure, we also managed to close ~30 outstanding issues with this rewrite and set us up to reach ~90% node:http compatibility, so overall I consider it a success.
Post reply on HN