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.
> The KV feature in the Deno runtime can be used without the hosting service.
But one writes to foundation, and the other writes to a sqlite file. You wouldn’t be able to self host an app written for Deno Deploy and have it work out of the box.
Are there any plans to open source the KV backend so that people could host their own KV databases? Now that you can connect to remote Kv databases, I suppose someone could implement their own?
This is what Java did - JCP created, APIs invented to be implemented by Tomcat, JBoss, fill in your favorite here. Configure your actual instance - in the past this was done with beautiful UIs - total waste of time considering we're in the era of Yaml (FBFW?) configuration.
This instantly reminded me of Next.js, which is open source but has a special build format for serverless environments.
The 1st party implementation is closed source: 3rd parties start on the back foot trying to implement alternatives and have to keep up with a 1st party that can move in lockstep.
And sure enough, like every other time I see this kind of behavior: Deno was invested in by the CEO of Vercel.
"Javascript is taken over by venture capital" wasn't on my 2023 bingo.
Vercel needs to stop with this bullshit. It is straight up predatory ”open” source. Like a trapper’s cage, there’s a convenient, tasty bait and then it’s too late.
Is it too cynical to say this might be a lesson devs need to learn the hard way?
Right now the JS community has whipped themselves into a frenzy into building on VC backed technology.
- They refuse to acknowledge that the loudest voices in the room are openly sponsored and invested in by the same VCs who own the companies behind said tech
- They see no issue with a lack of diversity in implementations, instead settling for "it's a standard". Of course, defining a standard without a healthy variety of implementations means you end up with standards that don't benefit from a wide range of voices until well after they land (see RSC)
At the end of the day, those two alone are a pretty harsh combo: A VC-backed network effect machine built across multiple brands, and high technical costs to building something that meets the collection of standards.
I don't think anyone but FAANG can really compete with that without also getting VC dollars, thus reinforcing the loop.
You can build a Next.js app and run it on a docker container or regular linux host almost anywhere. Vercel has some nice continuous deployment stuff built-in but I'm not sure how a Next.js app is locked into it at all.
Next.js and Vercel heavily push serverless deployment: 13 reworked the built-in API support to leverage Web Standards, which discarded interop with the a much larger server ecosystem in order to enable better edge support.
Yeah on the same note I developed a moderately complex app on Next but I hit a roadblock when I needed background job support, which is not natively supported (or at least at the time wasn't) on Vercel/other Next platforms and so it was never a priority for Next. Pushing serverless so hard also made deployments janky and production bugs weird when you tried to use things not supported by the underlying platform, AWS (don't remember the details now, but Node version was one of those).
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.
> 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.
> difference between `#include "myStringMap.h"` and `map[string]string` in C vs.g Go.
Except one is a language feature with custom syntax and the other is a library that could be implmented as a library just the same.
Not everyone in the ecosystem is going to use this because its not forced on them through syntax and espically because its inside deno and not node so barely anyone at all will use it.
> If Google started adding Google Cloud specific primitives natively to Go would you call that forward thinking as well?
Go actually ships with a quite forward thinking SQL interface. It's an abstract interface over a DB, and you just import the "driver" that powers it. The driver conforms to a standard interface, so all of them behave roughly the same.
I think this is what everyone wants from Deno/etc - why can't there also be a KV interface that's universal, or a Queue interface that's universal?
People attempted this w/ go [1], where it attempts to use the same nice experience of the SQL logic, but it never seemed to gain traction.
> Go actually ships with a quite forward thinking SQL interface
SQL is low hanging fruit in this regard, because you just need to standardize the lowest common denominator flavors of SQL types for deserialization and then it's just juggling SQL queries around.
JDBC for Java does the same as database/sql and it's from 1997. ODBC is from 1992.
I don't think GP is saying that this is forward thinking, revolutionary level stuff, but rather that it's generally speaking a better thing to do than ship specific implementations that wall people into your solutions.
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
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.
I think people are hung up on a distinction between language and runtime that isn't that valuable and maybe doesn't even reflect normal use.
For example erlang ships a persistent KV store, queue, relational database and much more as part of its standard library. I've never heard anyone complain about this or wish it were otherwise.
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?