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

171–180 of 210 posts

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

#171

Post by leptons »

mosura wrote: post #26
wyuenho wrote: post #5

Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region. I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.

My gut feeling is that people want a modernized heroku. Managed RDBMS and an auto scaling set of servers that use it. That covers a massive proportion of the companies that don’t need or want massive scale.

If Deno were supported on AWS Lambda I might think about using it. FaaS on a major infrastructure provider is what I need. I'm not putting a project that means anything to me on Deno's servers, they aren't really leading the industry and might not be around in the blink of an eye the way the tech world is going lately.

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

#172

Post by int_19h »

mattlondon wrote: post #84
diggan wrote: post #13

Earlier quoted context omitted.

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? Yo…

Yep I control the stack, and I want it to be typescript. At this stage, I don't think anyone needs to try and persuade anyone why JavaScript and typescript are the Lingua Franca of software engineering. Performant, expressive, amazing tooling (not including node/npm), natively cross-platform. An absolute joy to code with. Why would anyone want to use anything else for general purpose coding? In my mind there are two…

It still doesn't have basics like tuples/records or pattern matching.

Something as simple as a map with two integers as a key, or case-insensitive string keys, requires jumping through hoops. Even Go and Python can do this.

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

#174

Post by ChocolateGod »

alabastervlog wrote: post #112
liveoneggs wrote: post #60

Earlier quoted context omitted.

Java has (much) better performance and a bigger ecosystem. It has types and multiple alternative languages which target it (kotlin, scala, clojure, etc)

Hell, last I checked PHP is still king of the server-side Web scripting languages, as far as real-world speed. Like, fast enough that you've gotta be pretty careful in Java or Go or whatever, or you'll end up slower than PHP. The way you make a scripting language fast is by getting the hell out of it and into C or C++ as fast as possible, and PHP's library ecosystem embraces that harder than just about any other scri…

Google has poured millions of $ and 100s of developers into the development of V8 to get every last inch of speed and optimisation. As far as comparing it to AOT/non-GC languages of course it will always be slower, but I would struggle to believe it's slower than PHP other than in specific situations.

Just one benchmark I could find https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#175

Post by int_19h »

diggan wrote: post #31
jgalt212 wrote: post #17

Earlier quoted context omitted.

maybe because async Python is painful, an async TypeScript / JS is the default.

Use another language where async isn't painful then? Since it's the backend, you have 100% control over what stack to chose, unless some other requirement gets in the way. And no, async isn't "the default" in at least JavaScript, not sure where you'd get that from.

It is the default in a sense that most libraries and increasingly many stdlib functions and even core language features require it. E.g. dynamic import() is async-only.

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

#176

Post by nicce »

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.

In Chrome, many of those bugs would be $5000 bounty and you don’t even need the exploit code.

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

#177

Post by quantadev »

When there's two competing technologies, and they're both solving the same problem, I always go with whatever's more popular, unless there's a compelling reason not to. This is mainly because of community support and having more companies/developers motivated to rapidly solve challenges that come up, and/or fix bugs.

But especially in the AI/LLM era it's even _more_ important to use what's most popular because the LLM will know more about it, and can pull information from vastly more resources, including it's most important "source" of all: The model weights.

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

#178

Post by Sytten »

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.

When you read the Bun codebase it is scary how they ignore edgecases. The codebase of Deno is actually legit, I used it as reference for LLRT modules.

This is really a case were Rust will shine compare to Zig.

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

#179

Post by FunnyLookinHat »

mark_and_sweep wrote: post #138
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…

> My favorite testing framework, AVA, still isn’t supported. Have you checked recently? The docs ( https://docs.deno.com/runtime/fundamentals/testing/ ) specifically mention AVA as being supported. Then again, I'd assume that most devs using Deno just use the built-in `deno test` instead of a third-party testing framework. > The one area of Node compatibility that I want the most is support for ESLint configs in the…

> And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.

I feel similarly. The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.

I've started using Deno in my spare time for various projects - and it just _feels_ more productive. I go from idea to testing TypeScript in minutes - which never happened in Node land.

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

#180

Post by foldr »

LoganDark wrote: post #39
diggan wrote: post #24

Earlier quoted context omitted.

> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere…

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 by design (for defensible reasons). It's a whole nother level of unsoundness in comparison to Go.

Post reply on HN