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

Deno 1.33: Deno 2 is coming

deno.com

Post reply on HN
Print view View original

21–30 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#21

Post by osener »

sph wrote: post #15
threatofrain wrote: post #14

Earlier quoted context omitted.

I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has preven…

[flagged]

Disgraceful?! I'd much rather OSS authors have an additional SaaS offering to support their work and work on it full-time rather than get them to work nights and weekends for free while AWS collects the checks for deploying their work.

Re: Deno 1.33: Deno 2 is coming

#22

Post by potamic »

billllll wrote: post #4

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering wheth…

It's a lock-in strategy. There is zero reason for a language runtime to be opinionated about the database. All the good programming advice will tell you such a coupling is a bad idea. What if you want to move parts of your application to a different language in the future, do you need to redo the entire database? That is just nuts!

Database providers, cloud application platforms should be agnostic of the language their users are using. There are many such decisions deno is making where they want to be the end-to-end service. That is not a good sign. It creates perverse incentives for the company to devise lock-in mechanisms at each stage and discourage compatibility with the rest of the programming ecosystem, perhaps even undermine the rest of the ecosystem. I would stay away for this reason.

Re: Deno 1.33: Deno 2 is coming

#23

Post by a1371 »

Deno's major adoption point can be it's native typescript support but without an easy way to bring an npm package into it, developing its community will be tough. So I can totally see why they are ployfilling `node:crypto` since many cloud SDKs are using those in their packages.

Re: Deno 1.33: Deno 2 is coming

#24

Post by wokwokwok »

csiegert wrote: post #13
wokwokwok wrote: post #10

Earlier quoted context omitted.

I dunno. Is having a database that happens to be a product you sell as part of your runtime good, or are you creating some mixed incentives here? Are you a database vendor now? If not, don’t build a database. If this is a mature product that someone else is looking after, and it’s good and free and we’ll maintained like redis or SQLite, sure. …but it seems like building cloud databases is not the core competency of a…

Deno Inc. has two core products: The free Deno runtime and the for-profit Deno Deploy, a Deno hosting service with 35 locations around the world. The question that often popped up was where to store data. Deno Inc. provided several guides to connect to different cloud services. But they want the friction reduced to a simple `await Deno.openKv()`. Deno Inc. has enough expertise in running a global service that two oth…

> The question that often popped up was where to store data. Deno Inc. provided several guides to connect to different cloud services.

Sure.

> But they want the friction reduced to a simple `await Deno.openKv()`.

Do “they”?

If so, who’s using it to solve that problem? …because it seems the big uses of deno deploy are not using it, fine with that and it’s pretty unclear who the “they” is in this circumstance.

Still, if it’s a thin layer over foundation db or some other established database product and this is just part of the lock-in for their cloud offering, fair enough.

It’s not like others (eg firebase) don’t do the same thing.

The messaging “we’re building a database” and “we’re offering a hosted database service based on existing mature reliable technology” are different things though.

The latter all cloud vendors do.

The former is ridiculous, and it really really wasn’t clear that wasn’t what was happening.

Re: Deno 1.33: Deno 2 is coming

#25

Post by [deleted] »

potamic wrote: post #22
billllll wrote: post #4

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering wheth…

It's a lock-in strategy. There is zero reason for a language runtime to be opinionated about the database. All the good programming advice will tell you such a coupling is a bad idea. What if you want to move parts of your application to a different language in the future, do you need to redo the entire database? That is just nuts! Database providers, cloud application platforms should be agnostic of the language the…

[deleted]

Re: Deno 1.33: Deno 2 is coming

#26

Post by lenkite »

tehbeard wrote: post #17

I'm a little thrown on the reasoning for shuffling round the std/encoding/* modules to std/* Seems like it would just clutter the std/* "namespace" and cause churn in dependencies?

Yeah, this is a very stupid change std/encoding/* is also actually the right place, why pollute the top level namespace with encodings ?

Re: Deno 1.33: Deno 2 is coming

#27

Post by forty »

threatofrain wrote: post #14
can3p wrote: post #3

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release. I consider this a JavaScript curse to be honest. Every webpack version breaks apis in rand…

I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has preven…

Their main issue IMO is that they are not really bringing anything major to the table in exchange for the very high cost of breaking compatibility with nodejs. If you are going to create a competing ecosystem it has to be somewhat revolutionary for the cost of investing/migrating to a whole new ecosystem to be worth it.

I like Typescript quite well, but if I'm told I'm going to throw away my nodejs/ts code base and start from scratch, then they are many alternative with better (for many definitions of "better") langages to consider, which at least will actually be different from what I have just thrown away.

Re: Deno 1.33: Deno 2 is coming

#28

Post by thepratt »

billllll wrote: post #4

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering wheth…

To me this is quite similar to the Erlang VM's ETS in-memory store. There's a lot of usefulness in ETS itself, especially how it distributes inside clusters. Having an easy to use, efficient, and optimized store as part of the language can be a good enabler. Only time will tell if it is/isn't.

Re: Deno 1.33: Deno 2 is coming

#29

Post by scotty79 »

billllll wrote: post #4

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering wheth…

I think what's nuts is that databases data structures are not built into the language/stdlibs. I can make an array but if I want to add an index so I can access it fast then I have to jump through some inordinate hoops. I can make an in memory hashmap, but if I want to persist it and keep accessing it fast directly from persistent storage suddenly things get unnecessarily complicated.

I think fast searchable file backed data structures should be primitives of any computer language and runtime.

Re: Deno 1.33: Deno 2 is coming

#30

Post by Aerbil313 »

nikanj wrote: post #18
iddan wrote: post #5

Earlier quoted context omitted.

The json structure is not a breaking change. You can use the old and the new structure

Why would you ever add the complexity of having to support two different formats then?

Old one will be deprecated in a major version change afaik.
Post reply on HN