Hacker News Reader

Comment by potamic | Hacker News Reader

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.

View on HN

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

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.

When not in deploy, you'd be stuck with a non distributed SQLite database for each instance your application is hosted on. There currently isn't a way to swap the backend for the deno kv API, so you would still need to update your code to use the new kv store that would have a different API. If you use redis instead, you'd be able to easily be able to switch providers by changing configuration options instead of having to update your code wherever it is used.

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

In that case, why does Deno have to provide this? Can't users simply create their own hashmap?

> 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.)

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

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.

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

How often does that happen?

Either way, it's not like you can't export your data and shove it into something else like redis.

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

Reply on news.ycombinator.com