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

Reports of Deno's Demise Have Been Greatly Exaggerated

deno.com

Post reply on HN
Print view View original

201–210 of 210 posts

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#201

Post by pier25 »

hombre_fatal wrote: post #189
pier25 wrote: post #148

Earlier quoted context omitted.

> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because they are losing something. All the time and money they are investing into node compat could have been used towards a Deno first party ecosystem. It's not like they have hundreds millions to spare. Deno is a small company with limited resources. People kept complaining that they couldn't use Deno with NPM packages so Deno end…

I think the upsides of Deno having its own isolated ecosystem are way overstated. In practice, it would stay a small group of hobbyists responsible for doing weird things like maintaining ports of npm libraries that deno users want, like official SDKs. It’s a grim end state if you’re trying to be more than that. And it seems to only appeal to people with a weird vendetta against Node/NPM which is also a crappy user t…

I'm not saying Deno should leave the ecosystem up to "a small group of hobbyists". What I'm arguing is that Deno investing in an official ecosystem would have been a better early investment than Node compat.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#202

Post by LoganDark »

foldr wrote: post #180
LoganDark wrote: post #39

Earlier quoted context omitted.

I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`…

>Go is unsound (Go slices...) What are you referring to here? Go's current slice implementation could only possibly introduce unsoundness via data races. Even there, I think you might actually need to muck around with an interface value rather than a slice to demonstrate unsoundness of the type system (rather than just memory corruption or unsafe memory access). Typescript's type system is just deliberately unsound b…

> What are you referring to here?

In this case my use of "unsound" is somewhat stretched to "particularly easy to make subtle mistakes as a programmer":

https://www.reddit.com/r/golang/comments/1h5ws8e/comment/m09...

https://build-your-own.org/blog/20241125_go_slice_surprise/

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#203

Post by pjmlp »

afavour wrote: post #100
skybrian wrote: post #45

Earlier quoted context omitted.

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people…

> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because you are losing something: a better ecosystem. Standardizing around… standards is a good thing. When I dive into the dependencies of any given Node app it’s a mess of transpiled code, sometimes minified even, there’s no guarantee what API it’ll be using and whether it’ll run outside Node (is it using the W3C streams API or th…

And now Python remains as the quoted example, alongside Perl 6, on what happens when breaking an ecosystem.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#204

Post by pjmlp »

ctz wrote: post #165
k__ wrote: post #99

It might just be my perception, but I had the impression Deno got his ass whooped by Bun and Node.js. While some people whine about the Node.js compat, I'd assume it's the main point that kept Deno on life-support in the long run. Bun did it right from the start and it seems people love it. Being quite a bit faster than Node.js (even with the compat APIs) and Deno obviously helps too. If they keep that going, they'd…

It is instructive to compare Bun and Deno's issue tracker. Like, the five most recent issues for Bun at the time of writing are all crashes. Some of these are controlled panics or assertion failures, but others are like "we are now executing from address -1" or "we are trying to read from address 0x00000069." Recently written software simply should not have these classes of problem.

That is what happens when the user base basically wants a Modula-2 with C syntax.

Yes, preferably safer than C ever was, but that isn't what a 21st century systems language is supposed to be.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#205

Post by pjmlp »

bredren wrote: post #69
CuriouslyC wrote: post #53

Earlier quoted context omitted.

Bun has high node compatibility with lightning fast testing and a good/fast built in package manger. I'd use bun for local dev even I was deploying with node.

Why not esbuild? It was ~fast enough first and free of capital entanglements.

And Go is much safer as implementation language.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#206

Post by CuriouslyC »

pjmlp wrote: post #205
bredren wrote: post #69

Earlier quoted context omitted.

Why not esbuild? It was ~fast enough first and free of capital entanglements.

And Go is much safer as implementation language.

Go is safer for networking heavy/performance critical services, but for anything that's IO/upstream limited the performance of Bun and Go will be comparable and there are more people who are node proficient/it lets people work across the stack with the same tooling.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#207

Post by pjmlp »

CuriouslyC wrote: post #206
pjmlp wrote: post #205

Earlier quoted context omitted.

And Go is much safer as implementation language.

Go is safer for networking heavy/performance critical services, but for anything that's IO/upstream limited the performance of Bun and Go will be comparable and there are more people who are node proficient/it lets people work across the stack with the same tooling.

What has that to do with Zig?

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#208

Post by babyent »

lolinder wrote: post #67
skybrian wrote: post #45

Earlier quoted context omitted.

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people…

An equivalent argument to yours could be made to defend the introduction of async/await to a language that has previously not had it (edit: like Rust): if you don't like async/await, just don't use it! What does it hurt you to have another feature added? The answer is obvious in the programming language case: for those who do not want async, the addition of async/await begins to poison the ecosystem. Now they have a…

Why are people so resistant to change lol just use the better stuff or migrate to it.

It’s software you are mostly using to build end user software. Gauge it by how well it works and serves the end user.

This is why AI is good. It will just force this SWE vintage to solve the problem at hand instead of over engineering or holding on to some traditionalist views of the language.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#210

Post by sholladay »

anon7000 wrote: post #187
sholladay wrote: post #81

I was excited about Deno precisely because it was a greenfield approach without backwards compatibility. Early on, they focused on reducing complexity and it worked. There were definitely some new pain points compared to Node, but I found them pretty manageable. At some point, rather than coming up with native solutions to those pain points, they retreated and started leaning on backwards compatibility as a workaroun…

Why are you complaining about npm compatibility while also complaining that they don’t have enough compatibility? Sounds like you want it both ways — for it to be very simple and purposeful, but also to broadly support lots of options from the Node ecosystem. Their purpose is to be a single toolchain & system for JS, and they’re solving a lot of problems in that area. No need to configure huge number of tools for a r…

I will re-frame it for you with emphasis. I do not want the complexity of npm compatibility in Deno. However, if they insist on it, then I at least want to be able to use my existing linting setup for consistency. That is the one silver lining that I would want to make use of. Yet, I can’t.

Instead, I got all the complexity without the benefit. That’s how I feel about it.

Post reply on HN