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

141–150 of 210 posts

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

#141

Post by imicrowaveforks »

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…

[flagged]

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

#142

Post by mattlondon »

rowanG077 wrote: post #140
hungryhobbit wrote: post #121

Earlier quoted context omitted.

Do you know what lingua franca means? https://survey.stackoverflow.co/2024/technology#most-popular... ... JS is the most popular language in the world, per Stack Overflow.

Do you know what it means? A lingua franca is able to facilitate communication between many parties who do not have a common mother language. JavaScript most certainly does not fit that bill. You could argue C is the lingua franca from the side of the CPU since C runs everywhere, it is literally meant for that. A portable assembly.

C does not run everywhere - you need to compile it to a binary per-platform and per-architecture first, then your platform+arch specific binary only runs on that specific combination... And even then there might be dynamically linked libs to worry about.

You may as well call binary (i.e. 1s and 0s) the Lingua Franca in that case.

Lets not get started on C build chains (especially cross-compiling) ... cmake Vs cygwin Vs msvc Vs whatever else these days with hacky-and-brittle ifdefs conditionals everywhere just to make it work - chaos! JavaScript just runs on pretty much any modern computer you can sit down at or put in your pocket, and even on more exotic things that don't have it installed by default you are about 10 seconds away from installing the official package and you are off and running.

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

#143

Post by monooso »

afavour wrote: post #105
skybrian wrote: post #104

Earlier quoted context omitted.

I haven’t done all that much network programming in Deno, but I think it’s still fairly easy to get “promises all the way down” by sticking with Deno API’s? What’s your experience with this?

My complaint is not with Deno APIs. From what I’ve seen they’re great. My problem arrives the moment you install a dependency, because it isn’t using Deno APIs. And digging into exactly what any dependency is doing is often an odyssey through transpiled-to-ES3 JavaScript, outdated APIs and so on. The original promise of Deno was a consistent ecosystem. Absent that it doesn’t matter to me all that much how great Deno…

Surely you can choose to only install "Deno native" dependencies?

It may sometimes be difficult to find such an option, but that was always going to be the case without Node compatibility.

Now, in theory at least, you have the option of sticking with Deno native dependencies, and an escape hatch when none are available.

That seems like the most pragmatic solution to the ideology vs adoption dilemma.

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

#144

Post by 1vuio0pswjnm7 »

afavour wrote: post #7

I’m sure a bunch of the criticism of Deno is exaggerated. But there’s something fundamental holding me back from investing my time in Deno, or Bun for that matter: they’re both VC funded. The post is a good illustration of why that matters. Very little of it is about Deno itself, instead it’s mostly about the paid-for services Deno Inc offers. They have to prioritise and chase that because their investors want to see…

"But there's something fundamental holding me back from investing my time in Deno, or Bun for that matter: they're both VC funded."

For me it is the lack of support for musl. Perhaps there is a connection between inattention to certain details and being VC-funded.

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

#145

Post by ogoffart »

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…

Off-topic, but the idea of "colored functions" from the "What Color is Your Function" article doesn't apply to Rust's async/await. That article is about JavaScript before it had async/await, when it used callbacks.

In Rust, you can call async functions from normal ones by spawning them on the executor. The .await syntax isn't as painful as dealing with callbacks and closures in JavaScript. Plus, if you call an async function incorrectly, Rust's compiler will catch it and give you a clear error message, unlike JavaScript, where bad function calls could lead to unpredictable behavior. The premises of the article don't apply, so Rust's async/await doesn't introduce the same "colored function" issues.

(See also https://without.boats/blog/let-futures-be-futures/ )

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

#146

Post by lolinder »

ogoffart wrote: post #145
lolinder wrote: post #67

Earlier quoted context omitted.

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…

Off-topic, but the idea of "colored functions" from the "What Color is Your Function" article doesn't apply to Rust's async/await. That article is about JavaScript before it had async/await, when it used callbacks. In Rust, you can call async functions from normal ones by spawning them on the executor. The .await syntax isn't as painful as dealing with callbacks and closures in JavaScript. Plus, if you call an async…

I read the article when it hit HN months ago but I don't agree that function coloring doesn't apply. What you're describing is that Rust makes coloring less painful, not that functions aren't colored.

JavaScript itself has come a long way towards making coloring less painful. TypeScript+ESLint solves the weird unpredictable behavior issues with JS and async/await solves the syntax issue. Promises in general give well-defined semantics to calling an async function from a sync function. But all that only undoes some of the arguments about function coloring, not all of them. Fundamentally the same question applies: do you make async-ness part of the type system or do you instead build a system like green threads that doesn't put it in the type system?

I happen to think that coloring functions according to their async-ness is actually the right move (with the right ergonomic improvements), but plenty of people don't agree with me there even with all the ergonomic improvements Rust and TypeScript have made to the model.

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

#147

Post by pier25 »

mattlondon wrote: post #6

I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with…

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node?

Cloudflare Workers workerd comes to mind but it's fundamentally a different thing.

https://github.com/cloudflare/workerd

It's not meant to be a generalist backend runtime and it provides almost zero batteries.

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

#148

Post by pier25 »

skybrian wrote: post #45
mattlondon wrote: post #6

I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with…

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 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 ended up focusing in providing faster horses.

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

#149

Post by rowanG077 »

mattlondon wrote: post #142
rowanG077 wrote: post #140

Earlier quoted context omitted.

Do you know what it means? A lingua franca is able to facilitate communication between many parties who do not have a common mother language. JavaScript most certainly does not fit that bill. You could argue C is the lingua franca from the side of the CPU since C runs everywhere, it is literally meant for that. A portable assembly.

C does not run everywhere - you need to compile it to a binary per-platform and per-architecture first, then your platform+arch specific binary only runs on that specific combination... And even then there might be dynamically linked libs to worry about. You may as well call binary (i.e. 1s and 0s) the Lingua Franca in that case. Lets not get started on C build chains (especially cross-compiling) ... cmake Vs cygwin…

Obviously "Run everywhere" is after compilation. No language works without some kind of processing, and no machine code is not a language. Even if you'd call machine code a language it cannot be called a lingua franca by definition since it's designed to be architecture specific. I'm not sure why you are even start with linked libs, or even linking or libraries at all. That's far removed from the language itself, the C language standard does not prescribe how to link even. It's an implementation detail.

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

#150

Post by coolcase »

koakuma-chan wrote: post #42
coolcase wrote: post #38

Earlier quoted context omitted.

You don't need to deal with those anyway. RPC it. fetch one one end, route on other.

> RPC it. fetch one one end, route on other. What do you mean by this?

JS fetch function in three browser.

Add a route on the back end.

RPC means just call it! don't worry about REST, GQL etc.

Post reply on HN