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

51–60 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#51

Post by Sai_ »

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…

iOS apps have an opinion about which Db to use and why it should be core data.

Re: Deno 1.33: Deno 2 is coming

#52

Post by re-thc »

frou_dh wrote: post #16
jatins wrote: post #11

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

The equivalent of Next.js would be Deno + their "Fresh" web framework. https://fresh.deno.dev/ My impression of Fresh is that it's neat technology but basically a barebones MVP at this stage. They haven't done much development on it since v1 last year, presumably because the team has been busy with other stuff like what's described in the article.

It uses Preact other the hood which often has edge cases vs React and its ecosystem, which makes adoption harder.

Re: Deno 1.33: Deno 2 is coming

#53

Post by flohofwoe »

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 not really built into the language though? It's just a function on the global Deno object, similar to how there's a global 'document' object in browsers (and that's not 'built into the language' either).

Re: Deno 1.33: Deno 2 is coming

#54

Post by lloydatkinson »

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…

Netlify edge workers use only Deno

Re: Deno 1.33: Deno 2 is coming

#55

Post by frou_dh »

lenkite wrote: post #26
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 ?

How's it namespace pollution? It won't cause any clashes in either std or the user's code. It's just a few directories moving slightly higher up in a directory structure (which as an aside, is even deeper than you might think, because it also includes the deno.land domain, remember).

Re: Deno 1.33: Deno 2 is coming

#56

Post by iudqnolq »

jabradoodle wrote: post #49
p-e-w wrote: post #33

Earlier quoted context omitted.

> 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…

I'm not familiar with the offering but find your comment confusing. It seems to suggest there isn't lock in because it's just a hashmap, but also that it is globally replicated and consistent.

If you don't deploy to deno cloud it's just SQLite and not distributed.

If you do deploy to deno cloud it's trivial to migrate because there are many competing offerings of kv stores.

Re: Deno 1.33: Deno 2 is coming

#57

Post by sph »

xupybd wrote: post #45
sph wrote: post #15

Earlier quoted context omitted.

[flagged]

I like to get paid for my work. Most people do. There is nothing disgraceful about that. I don't see any difference between deno as a company and your SAAS bernard.app.

My SaaS is not an open source project nor a language runtime. How would you feel if Go, Elixir or Rust (just to name a few) were run by a company that depends on their success, so try to push aggressively new features and mindshare, often with disastrous result?

Are Go, Elixir or Rust developers working for free? There is a difference between getting paid to work on open source, and structuring an open source company as a VC-backed startup that needs to grow fast or die.

I guess everyone has already forgotten about Docker, Inc.

Re: Deno 1.33: Deno 2 is coming

#58

Post by iudqnolq »

ohgodplsno wrote: post #46
frou_dh wrote: post #37

Earlier quoted context omitted.

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.

It is nefarious when you build up your entire product for years, spamming it everywhere as "node but better", yell "it's so open source too!" on every roof, only to sneakily slide in lock-in features, it's worse than being nefarious. You most likely had this plan in mind all along, and actively lied to get there. Watch as the same happens with Bun.

In this specific case I think it's super reasonable.

The KV store has two backbends: local sqlite and distributed deno cloud.

If you choose the deno cloud backend you're signing up for a closed source cloud service from the start. There's no trickery.

Re: Deno 1.33: Deno 2 is coming

#59

Post by jabradoodle »

iudqnolq wrote: post #56
jabradoodle wrote: post #49

Earlier quoted context omitted.

I'm not familiar with the offering but find your comment confusing. It seems to suggest there isn't lock in because it's just a hashmap, but also that it is globally replicated and consistent.

If you don't deploy to deno cloud it's just SQLite and not distributed. If you do deploy to deno cloud it's trivial to migrate because there are many competing offerings of kv stores.

If no claim of compatibility with other backends is provided I would be skeptical that it will be trivial by necessity.

I'm not that familiar with either technology, but as an example, deno kv claims strong consistency as the default; while dynamodb requires you to explicitly ask for strong consistency in queries and does not support strongly consistent reads on secondary indexes.

Re: Deno 1.33: Deno 2 is coming

#60

Post by Sheepsteak »

a1371 wrote: post #23

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.

You can import npm packages now. They added it a few release ago.

https://deno.com/manual/node

Post reply on HN