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

81–90 of 127 posts

Re: Deno 1.33: Deno 2 is coming

#81

Post by [deleted] »

p-e-w wrote: post #33
potamic wrote: post #22

Earlier quoted context omitted.

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…

[deleted]

Re: Deno 1.33: Deno 2 is coming

#82

Post by ithkuil »

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?

Because the new format is easier for their (new) users but removing the old one would be a pita for their (existing) users.

You can't get things 100% right all the times so you have to decide what to do when you realize there is a better way. You have a few choices:

a. You don't improve the interface and instead you offset the issue by adding more documentation, helper scripts, templates/examples etc.

b. You improve the interface, possibly in a backwards compatible way.

So, (b) presents some maintenance costs, but (a) too has some costs! Some organizations tend to prefer (a) because it's easier to just make it somebody else's problem (e.g. some other team will do documentation, some other team will do the developer advocacy).

So it's a locally optimal solution and hence it's often chosen despite (b) being a globally optimal solution, since the product will be easier to use.

Re: Deno 1.33: Deno 2 is coming

#83

Post by qbasic_forever »

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…

Uh oh better tell python to get rid of pickle and _sqlite3_ modules from its standard lib. Seems too opinionated...

Re: Deno 1.33: Deno 2 is coming

#84

Post by weatherlight »

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 Erlang runtime has Mnesia and ETS built in. Batteries included. It's awesome.

* Python has a built-in persistent key-value store, dbm.

* Ruby has one as well, pstore.

Now, you can always decide to use something else! 99% of the time m not going to use dbm, or pstore, but they are nice to haves. (Mnesia and ETS rocks though, and I use those all the time.)

Re: Deno 1.33: Deno 2 is coming

#85

Post by schemescape »

conaclos wrote: post #61

Something that still stop me from using Deno is the incompatibility between Deno and other tooling regarding the import of TypeScript files. Namely, it is not possible to import a `.ts` file via a `.js` import [0]. [0] https://github.com/denoland/deno/discussions/18293

Yeah, this is an annoying problem because it prevents the same code form working in both Deno and everywhere else.

Most frustrating is that (last I checked) there isn’t even an agreed upon plan to resolve the inconsistency, at least for libraries (import maps, though tedious, at least can solve the problem for non-library code).

Re: Deno 1.33: Deno 2 is coming

#87

Post by pier25 »

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…

This KV thing is not meant to replace your main database. I see it more for catching at the edge.

Yeah maybe you'd prefer to do that with an agnostic solution like Redis (which afaik is possible in Deno) but everything has pros and cons. An e2e solution is coupled but otoh it has many objective advantages. And it's not like Deno will force you to use their cloud service after all.

Re: Deno 1.33: Deno 2 is coming

#88

Post by faitswulff »

datadeft wrote: post #65

Didn't take too long to start the 2.0 version. I really like how Rust does not do this.

I wonder if they considered an edition like system for Deno versions. I would say that it’s likely too much upkeep for a commercial project, yet I somehow doubt that the Rust project has more capacity, whether that’s funding or engineering resources.

Re: Deno 1.33: Deno 2 is coming

#89

Post by yoav »

Bun, deno, now supabase, they’re all trying to build custom runtimes with everything included from database to SSR react island based frameworks.

I think it’s a cool idea generally, but let’s not mistake deno for replacing a generalized runtime. Deno, bun, etc. are proprietary infrastructure in a box that are being designed to integrate tightly with the rest of their deployment platforms

Re: Deno 1.33: Deno 2 is coming

#90

Post by qbasic_forever »

I love the direction deno is going with a batteries included standard library for server side JS. It makes so much sense to me to consider it for simple stuff so I could have backend and frontend code all in modern JS or typescript. Things like internal tools, dev tools, etc. that just need to pop some HTML, rendered markdown, collect a few forms, run some business processes, etc. No need to wrestle the node ecosystem, no need to context switch between backend and frontend code with other languages like python.

I really think this has a strong future in enterprise as dedicated frontend, backend and devops roles all merge into one. Everyone just learns and uses typescript for everything. Everyone is a 'full stack' engineer now. I hate to say it but it's almost like the dream of java all over, except the language and tooling isn't painful.

Post reply on HN