Re:Deno 2.4
by voat on Monday July 07, 2025 @06:06AM
(#44488607)
People underestimate the node compatibility that Deno offers. I think the compat env variable will do a lot of adoption. Maybe a denon command or something could enable it automatically? Idk.
[ Parent
| on HN ]
Re:Deno 2.4
by CuriouslyC on Monday July 07, 2025 @07:33AM
(#44489197)
Honestly, I was bullish on Deno back in the day, but I don't see why I'd use it over Bun now.
Less segfault, improved security / capability model
The security model is very underestimated imo, it will be very evident when more bun projects reach production and not experimental.
Re:Deno 2.4
by spiffytech on Monday July 07, 2025 @08:55AM
(#44489907)
As a Bun user I don't really get segfaults anymore.
I've written C for years. The only time it is safe from crashes is when the code doesn't churn and has consistent timing between threads. bun has constant feature churn and new hardware it runs on all the time providing novel timings. It is very unlikely going to be crash free any time soon.
Just got one today! But yes it is better.
[dead]
If you want to use rust, and it fits your use case, then use rust. Same as with any language choice if itβs the right thing for you then go ahead.
I have a few million lines of existing TypeScript so will keep using JS runtimes for the foreseeable future.
I have yet no reason to fight IT and architects for having anything besides node on CI/CD pipelines and base images for containers.
The deno compatibility with node has been a lie for me. I tried to port a simple project (100-200 LOC) to deno and it took me an hour which should have been 5-10 minutes. It didn't support some of node's methods and if it did, it was completely undocumented. Had to install basic functionality from some obscure URLS. Onxe it came to porting my test suite I just gave up. The problem was CJS -> ESM transition that was way more painful than I anticipated it to be. And definitely not as simple as deno's docs make it to be. Couldn't just port the whole library