5 ms·

I think what Deno is aiming for here is actually very forward thinking. I'm using Go for the first time this year and some aspects of the language are very C l

I think what Deno is aiming for here is actually very forward thinking. I'm using Go for the first time this year and some aspects of the language are very C like. Of the list of things that isn't C like (e.g. GC allowing one to return what look like stack allocated pointers from functions) there is the obvious inclusion of things like `map[string]string`. I bring this up because it struck me that inventing a language in 2023+, it would seem almost insane not to have built in syntax for the language to handle map types. And so it seems logical that a web-server focused eco-system would start to garner libraries and even language syntax (maybe one day) for the kind of primitives we frequently use on web-servers. I mean, I can't even recall the last time I worked on a distributed web server that didn't have a KV store as a cache, or a locking mechanism, or even an ad-hoc queue. A distributed system without a KV store feels vaguely isomorphic to a computer language without a map type. It is such a Swiss army knife kind of technology. One potential issue is that Deno is going alone down this path. Currently, I don't feel confident that the new features they are adding will be available on competing platforms. Even if they open source the API (it is on a `Deno` namespace), I'm not sure it will just work on AWS if I wanted to switch out FoundationDB for e.g. Redis. For that reason, I feel I want to avoid Deno. Even if the syntax and exposed features are really attractive, I'm worried about becoming locked in and then having to do a lot of surgery to code to make it deployable on multiple cloud infrastructures. That is a requirement from a lot of clients. E.g. maybe I want to sell to Oracle or Salesforce one day but they mandate I have to run my systems on-prem. I'm now on the hook trying to figure out how to adapt whatever available KV store they have to the features I'm using from the `Deno` package. It is a double edged sword. Maybe they will succeed in pushing forward this vision to a broader audience. For now I'll probably remain cautious.

paxys 3y ago
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?
- coffeebeqn 3y ago
  If they want to have these primitives then I’d prefer to have a “universal” queue API that would work with SQS, Kafka, etc. with some magic. But the developer API could be just deno.Queue or whatever
  - paxys 3y ago
    Why try to standardize the interface at all? This isn't the job of a programming language, and there is no way it can anticipate all the possible use cases. Let each service publish their own bindings, and you can a programmer can consume whichever ones you want.
    - dkn 3y ago
      Deno is not a programming language though. It's a JavaScript (TypeScript) runtime. Deno is basically trying to be an infrastructure framework for JavaScript.
- zoogeny 3y ago
  > What is really the difference between Deno.KV being shipped as a standard library vs adding an `import KVService` statement at the top of the file? The same difference between `#include "myStringMap.h"` and `map[string]string` in C vs.g Go. There is some advantage to everyone in an ecosystem using the same primitives. That kind of language-level standardization goes a long way. For example, it might increase the ecosystem of available distributed system libraries that only need KV stores. If I can compose several libraries, all of which use the same underlying KV interface and implementation - I can imagine that might result in some interesting use-cases. As for the rest of your comment, I would humbly ask if you read the entirety of my comment? We seem to agree that as long as Deno KV is locked into their cloud that people should be very wary of lock in. And I myself will likely avoid it for the time being until the dust settles. There is some chance the rest of the community will just come along and fill in the gaps on popular cloud platforms. Or maybe they won't. Time will tell.
  - 3y ago
jadbox 3y ago
I love Deno but I'm cautious on adopting for the same reasons. It seems like Deno can only win if they fully support their hosting competitors as well. At the same time, they will need to be as-good or better at hosting as the industry leaders. Alternatively Deno could decide to drop their own hosting and offer a multi-cloud solution with a slim margin over their hosting partner adapter. With this path, Deno wouldn't have to directly compete as a hosting provider.
ecnahc515 3y ago
> e.g. GC allowing one to return what look like stack allocated pointers from functions I think this is due to having escape analysis and SSA rather than having a GC.
johnspurlock 3y ago
In this case, they've also documented the remote connection protocol: "KV Connect" https://github.com/denoland/deno/tree/main/ext/kv#kv-connect https://github.com/denoland/deno/tree/main/ext/kv#kv-connect I kicked the tires on this with a pure TS implementation of the protocol called kv-connect-kit that gives you the KV client api in any Javascript runtime (including Cloudflare workers, which does not have anything Deno namespace related) - github: https://github.com/skymethod/kv-connect-kit https://github.com/skymethod/kv-connect-kit - npm: https://www.npmjs.com/package/kv-connect-kit https://www.npmjs.com/package/kv-connect-kit - deno/x: https://deno.land/x/kv_connect_kit https://deno.land/x/kv_connect_kit - demo: https://keyspace.deno.dev/ https://keyspace.deno.dev/ protocol seems to works as described on the tin, and it would be pretty straightforward to write another backend
- jamesmcintyre 3y ago
  This library looks really cool, love the idea of unifying the api across various envs is great!
ljm 3y ago
Deno is just trying to compete with other JS/TS SaaS with this. Vercel/NextJS has a KV service now; Cloudflare has it; in other cases it's Firebase. I contend that this is not actually forward thinking, but monetising Deno as a SaaS, which every man and his dog is doing in the JS world lately with their 'cloud' offerings (reselling AWS with a framework). That's why there is a pricing page attached to this. If Deno's KV depends on FoundationDB then they're hardly going to build adapters over other databases - switching DB tech is always a massive ordeal because they all have different use-cases and performance characteristics.
papichulo2023 3y ago
Postgres connector actually supports encoding and decoding map[string]interface{} to json and jsonb data types, quite cool.

paxys 3y ago

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?

coffeebeqn 3y ago
If they want to have these primitives then I’d prefer to have a “universal” queue API that would work with SQS, Kafka, etc. with some magic. But the developer API could be just deno.Queue or whatever
- paxys 3y ago
  Why try to standardize the interface at all? This isn't the job of a programming language, and there is no way it can anticipate all the possible use cases. Let each service publish their own bindings, and you can a programmer can consume whichever ones you want.
  - dkn 3y ago
    Deno is not a programming language though. It's a JavaScript (TypeScript) runtime. Deno is basically trying to be an infrastructure framework for JavaScript.
zoogeny 3y ago
> What is really the difference between Deno.KV being shipped as a standard library vs adding an `import KVService` statement at the top of the file? The same difference between `#include "myStringMap.h"` and `map[string]string` in C vs.g Go. There is some advantage to everyone in an ecosystem using the same primitives. That kind of language-level standardization goes a long way. For example, it might increase the ecosystem of available distributed system libraries that only need KV stores. If I can compose several libraries, all of which use the same underlying KV interface and implementation - I can imagine that might result in some interesting use-cases. As for the rest of your comment, I would humbly ask if you read the entirety of my comment? We seem to agree that as long as Deno KV is locked into their cloud that people should be very wary of lock in. And I myself will likely avoid it for the time being until the dust settles. There is some chance the rest of the community will just come along and fill in the gaps on popular cloud platforms. Or maybe they won't. Time will tell.
- 3y ago

jadbox 3y ago

I love Deno but I'm cautious on adopting for the same reasons. It seems like Deno can only win if they fully support their hosting competitors as well. At the same time, they will need to be as-good or better at hosting as the industry leaders. Alternatively Deno could decide to drop their own hosting and offer a multi-cloud solution with a slim margin over their hosting partner adapter. With this path, Deno wouldn't have to directly compete as a hosting provider.

ecnahc515 3y ago

> e.g. GC allowing one to return what look like stack allocated pointers from functions I think this is due to having escape analysis and SSA rather than having a GC.

johnspurlock 3y ago

In this case, they've also documented the remote connection protocol: "KV Connect" https://github.com/denoland/deno/tree/main/ext/kv#kv-connect https://github.com/denoland/deno/tree/main/ext/kv#kv-connect I kicked the tires on this with a pure TS implementation of the protocol called kv-connect-kit that gives you the KV client api in any Javascript runtime (including Cloudflare workers, which does not have anything Deno namespace related) - github: https://github.com/skymethod/kv-connect-kit https://github.com/skymethod/kv-connect-kit - npm: https://www.npmjs.com/package/kv-connect-kit https://www.npmjs.com/package/kv-connect-kit - deno/x: https://deno.land/x/kv_connect_kit https://deno.land/x/kv_connect_kit - demo: https://keyspace.deno.dev/ https://keyspace.deno.dev/ protocol seems to works as described on the tin, and it would be pretty straightforward to write another backend

jamesmcintyre 3y ago
This library looks really cool, love the idea of unifying the api across various envs is great!

ljm 3y ago

Deno is just trying to compete with other JS/TS SaaS with this. Vercel/NextJS has a KV service now; Cloudflare has it; in other cases it's Firebase. I contend that this is not actually forward thinking, but monetising Deno as a SaaS, which every man and his dog is doing in the JS world lately with their 'cloud' offerings (reselling AWS with a framework). That's why there is a pricing page attached to this. If Deno's KV depends on FoundationDB then they're hardly going to build adapters over other databases - switching DB tech is always a massive ordeal because they all have different use-cases and performance characteristics.

papichulo2023 3y ago

Postgres connector actually supports encoding and decoding map[string]interface{} to json and jsonb data types, quite cool.