I disagree. Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking. In fact the tech industry has made a lot of progress away from vendor locked-in stacks, and this just reminds me of those.
What is really the difference between Deno.KV being shipped as part of the runtime vs adding an `import KV` statement at the top of the file (which could come from Deno or wherever else you want)?
And what are the chances that the Deno team is going to ship bindings for any language besides their own?
If Google started adding Google Cloud specific primitives natively to Go would you call that forward thinking as well?
> Tying a language runtime to a specific KV interface which is tied to a specific hosted service is the opposite of forward thinking.
This is not the case. The Deno runtime itself is not tied to the Deno Deploy hosting service. The KV feature in the Deno runtime can be used without the hosting service.
You can read the details about how Deno KV works in the Deno runtime here: https://til.simonwillison.net/deno/deno-kv (as has been posted in other comments)
This is not true, you cannot run your own foundationdb server and use the kv service without reimplementing yourself in fdb
This sentiment has been repeated in a few comments. But, why can’t the deno deploy implementation be reimplemented, by yourself, by running a foundationDB server with mvSQLite[1]?
That shouldn’t require any changes to the code.