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

31–40 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#31

Post by olric »

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…

[dead]

Re: Deno 1.33: Deno 2 is coming

#32

Post by olric »

ohgodplsno wrote: post #20
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…

Building a KV store into the runtime, that has more features when using deno deploy is just that: vendor lock-in. It's just one more way to force you into paying for the service when you have locked yourself in and you can't use an alternative store. Deno is not and has never been an "alternative runtime" to node.

[dead]

Re: Deno 1.33: Deno 2 is coming

#33

Post by p-e-w »

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…

> There is zero reason for a language runtime to be opinionated about the database.

The API is extremely simple. It's little more than a hash map. That's hardly opinionated.

> All the good programming advice will tell you such a coupling is a bad idea.

That advice is outdated. Virtually any modern application will want a database, and this API can serve as a foundation for it – a foundation that conveniently already has many of the features (esp. global replication and consistency) that you will want and that are incredibly difficult to get right if you build them yourself. Think of this as the application's "file system". PaaS today usually doesn't provide direct disk access, so this is the low-level abstraction for persistent storage that is available. An abstraction that, in many cases, will in fact be all your application ever needs.

Re: Deno 1.33: Deno 2 is coming

#34

Post by pjmlp »

While it is interesting to see the work going on this, unless something really messes up node, I don't see any big adoption ever taking off, other than how egcs forced GCC to come back on track.

Re: Deno 1.33: Deno 2 is coming

#36

Post by suction »

wokwokwok wrote: post #10
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 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…

[dead]

Re: Deno 1.33: Deno 2 is coming

#37

Post by frou_dh »

ohgodplsno wrote: post #20
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…

Building a KV store into the runtime, that has more features when using deno deploy is just that: vendor lock-in. It's just one more way to force you into paying for the service when you have locked yourself in and you can't use an alternative store. Deno is not and has never been an "alternative runtime" to node.

If they provide a compelling product offering, and the people understand what's available where, and choose to use it, then I guess that can be called vendor lock-in. But it's hardly nefarious.

Re: Deno 1.33: Deno 2 is coming

#38

Post by lacasito25 »

StefanWestfal wrote: post #2

Nice to see ongoing development and a view ahead. For work I would need a good interface for SQL. In pet projects I am using sqlx for Rust and sqlc for Python. In both you can write SQL directly and get query validation and parsing into struct / PyDantic for free. Is there something like this for Deno?

There's pgtyped, which I believe does almost the same as sqlc

https://github.com/adelsz/pgtyped

Re: Deno 1.33: Deno 2 is coming

#39

Post by gorbypark »

jatins wrote: post #11

Anyone using Demo in production? If yes, what's your experience has been as compared to, say, Next.js?

I am using Supabase in production (small DAU app for a large company), which uses Deno Deploy as their function provider. So far no issues and it works well. It’s also quite easy coming from a nodejs / browser js background to pick up, as it’s just JavaScript after all.

Re: Deno 1.33: Deno 2 is coming

#40

Post by presentation »

pjmlp wrote: post #34

While it is interesting to see the work going on this, unless something really messes up node, I don't see any big adoption ever taking off, other than how egcs forced GCC to come back on track.

The only true benefit I’m seeing as a potential Deno user is the faster startup time to reduce cold boots in a serverless setting - everything else is more in the category of “nice to haves” like ease of setup (I’m used to the workflows with Node so while it’s obtuse it’s something I know and is well documented on the web) and a tighter security model (I haven’t personally ran into any issues with this in Node but can see the benefits).

But nothings stopping Node devs from prioritizing the cold boot time, or for other upstarts like Bun with more of a focus on maintaining Node compat, or going with V8 Isolates instead, to give Deno a solid run for its money.

Post reply on HN