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

Deno 2.8

deno.com

Post reply on HN
Print view View original

161–170 of 193 posts

Re: Deno 2.8

#161

Post by ngrilly »

hollowturtle wrote: post #124
VerifiedReports wrote: post #71

Earlier quoted context omitted.

All good questions. But... it would simply eliminate a step and result in a single language. Python supports types and is interpreted, right?

Interpreted that's right, in fact it's super slow and adding types adds up to parsing time. Javascript is jitted. Python types serves no purpose if not for documenting or letting the lsp doing some lightweight type checking. And btw typescript introduced many breaking changes and the spec is managed by microsoft something you don't want for the open web. What we would really benefinit from would be having WASM being…

Python type annotations are available at runtime, which can be used for serialization and validation (for example in FastAPI).

Re: Deno 2.8

#163

Post by bel8 »

tuananh wrote: post #47
Curosinono wrote: post #41

I don't get it why the hell is TypeScript still not nativly supported in modern browsers?

JS promise to never break the web. can't say the same about TS

JS can't really break the web.

It's a trillion+ market.

If that ever happens for some exquisite reason, it would be forked in under 2 milliseconds by the browser consortium.

Re: Deno 2.8

#164

Post by vrighter »

AgentME wrote: post #117
cptmurphy wrote: post #114

Earlier quoted context omitted.

Deno permission system is so basic. What you need is capability system

Javascript/Typescript as it is now isn't a great language for a real capability system because any code can monkey-patch global objects and use that to steal capability objects from elsewhere. JS code of different privilege levels needs to be run in separate realms at the very least. (Though there are proposals for things like frozen realms that try to make JS more suitable for capability systems.)

one more reason I would have preferred a world in which lua was used in js's place

Re: Deno 2.8

#165

Post by danborn26 »

The steady release cadence for Deno has been impressive to watch. Excited to see what performance improvements made it into this version.

Re: Deno 2.8

#166

Post by mcdonje »

lenkite wrote: post #160
MrJohz wrote: post #122

Earlier quoted context omitted.

I think the biggest issue with Deno is that it fixes real issues but in the wrong way. Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will c…

Are there languages and runtimes which have done stuff at this low-level before ? Sandboxing at the individual function level ?

seL4 is an operating system that uses capabilities

Re: Deno 2.8

#167

Post by shimman »

refulgentis wrote: post #58
darkwi11ow wrote: post #23

Earlier quoted context omitted.

Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.

What happens if Anthropic and OpenAI shut down? Is it different from the status quo prior?

No, the same thing always happens. The community latches onto a new project where all the effort is spent chasing previous gains, then they get bought out, and over time the same pattern appears.

At this point our industry would benefit from public investment in open source in the form of grants rather than relying on corporate benefactors to not rat fuck the commons.

Re: Deno 2.8

#168

Post by wiseowise »

dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

> Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?

Bundler + used by Claude Code, that’s pretty much it.

Re: Deno 2.8

#169

Post by wiseowise »

chamomeal wrote: post #119
dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node. Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier…

> Node always felt immature compared to stuff like go or java.

Not enough boilerplate and EnterpriseBeanFactorySingleton?

Re: Deno 2.8

#170

Post by pier25 »

dan_rock_wilson wrote: post #26

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support. I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime? Just the permission system alone (though I wish it extend…

Bun doesn't require special tooling since it uses standard TS and follows the Node conventions. With Deno you need special tooling for eg the weird import system and package manager.

Bun also includes stuff that you'd need a third party dependency with Deno or Node. Eg: database drivers, S3 client, etc.

Finally, Bun overall has better performance and efficiency compared to Deno.

That said, I'm going back to Node after the recent Bun fiascos with their Rust AI re-write.

Post reply on HN