I find deno to be very exciting. Viable business model, great ergonomics, glorious lack of bullshit configuration busywork.
What makes you believe that Deno has a viable business model?
Deno Queues
41–50 of 168 posts
Re: Deno Queues
#42Earlier quoted context omitted.
They actually have zero documentation I can find for using DenoKV outside of the Deno Deploy environment. It may be possible, or you can always use Deno without using DenoKV, but I think the statement "you have to use their hosted service" isn't inaccurate.
The first page of their documentation [0] mentions this: > Opening a database > In your Deno program, you can get a reference to a KV database using Deno.openKv(). You may pass in an optional file system path to where you'd like to store your database, otherwise one will be created for you based on the current working directory of your script. In fact, only the last page in the documentation speaks about KV on Deno D…
Passing a path to the local filesystem for the SQLite database only applies to local development; it does not speak to how to connect to e.g. a remote-hosted FoundationDB cluster.
But, I think this section hints at how it could be done [1]. Its phrased in the context of connecting to the DenoKV-hosted database from outside Deno Deploy, but it seems like the reverse could also be accomplished with the same API.
[1] https://docs.deno.com/kv/manual/on_deploy#connect-to-managed...
Re: Deno Queues
#43Earlier quoted context omitted.
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…
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.
Re: Deno Queues
#44I don't want my programming language to "implement" task queues and charge me for it. What is this edit: people seem to be getting hung up on the "runtime" v "programming language" distinction. I'm not sure why--it's weird to me that this is "part of the language + runtime" at all. Clearly, reasonable people can disagree about that, but hopefully on points more substantive than pedantic If tomorrow, someone started a…
> If tomorrow, someone started a for-profit company making a faster Python runtime and introduced features like this, it would be weird, and it would feel as pointless to me as Deno is
That's not really what Deno is. It's more vertical than purely a Python runtime-equivalent.
Having said that, the CPython runtime includes SQLite, so it's not far off anyway.
Re: Deno Queues
#45I 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 languag…
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…
> 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.
Re: Deno Queues
#46Earlier quoted context omitted.
They actually have zero documentation I can find for using DenoKV outside of the Deno Deploy environment. It may be possible, or you can always use Deno without using DenoKV, but I think the statement "you have to use their hosted service" isn't inaccurate.
Literally on the home page ( https://deno.com/kv ). > Don't want to use Deno Deploy? Deno KV works on any VPS, so you can deploy to your favorite cloud hosting service.
Marketing sites are not documentation.
Re: Deno Queues
#47I find deno to be very exciting. Viable business model, great ergonomics, glorious lack of bullshit configuration busywork.
I have tried to be excited about Deno, but just don't see it. What are they doing that hasn't already been done a hundred times in the past? Deno itself is essentially Node.js + automatic TS compilation (which would otherwise have been 1 extra config file). When the project launched they made a big deal about escaping from the messy NPM ecosystem, but then ended up having to turn around and add support for it, taking…
I think you're underestimating just how much tooling Deno has built-in. It's not just automatic TS compilation, but formatting, linting, testing, and benchmarking at the bare minimum. I use those for almost every project. Each of those would probably be at least another configuration file.
About Deno Deploy, I completely disagree with the analysis that it's just like any other lambda service. It's not just about easy deploys, the service itself is simply better. There are no cold starts and they don't just do that by keeping a vm up all the time. It's really magical. You should give it a second look.
Re: Deno Queues
#48I wonder how this differs from BroadcastChannel[1] which Deno already implements and DenoDeploy seems to support.
[1]: https://docs.deno.com/deploy/api/runtime-broadcast-channel
Re: Deno Queues
#49I don't want my programming language to "implement" task queues and charge me for it. What is this edit: people seem to be getting hung up on the "runtime" v "programming language" distinction. I'm not sure why--it's weird to me that this is "part of the language + runtime" at all. Clearly, reasonable people can disagree about that, but hopefully on points more substantive than pedantic If tomorrow, someone started a…
> If tomorrow, someone started a for-profit company making a faster Python runtime and introduced features like this, it would be weird, and it would feel as pointless to me as Deno is That's not really what Deno is. It's more vertical than purely a Python runtime-equivalent. Having said that, the CPython runtime includes SQLite, so it's not far off anyway.
> That's not really what Deno is. It's more vertical than purely a Python runtime-equivalent.
Can you explain further?
Thanks
Re: Deno Queues
#50Earlier quoted context omitted.
'.deno' files are not drop-in compatible with any other typescript-esque runtime, which I think is a reasonable enough bar to say that its a different programming language. And not just because of the standard library; Deno supports e.g. URL-based import paths, which have very low support in other ECMAScript-ish languages like Node. Generally: the terms "programming language" and "runtime" are synonymous. There are a…
Node is not a language.
Since you're going to be pedantic, I will be too.
Language is more than syntax. Language is the combination of Syntax and Meaning; its a system of communication. The word "Fooloofol" is syntactically correct English, but meaningless within the English language; and thus is not English. The english word "bark" is syntactically identical across more than one meaning; a dog barks next to the tree bark. Language isn't just syntax; its the entire system of understanding.
The statement "fetch("https://example.com")" is syntactically valid in any ECMAScript-compatible language. Its also syntactically correct Python, Go, Rust, and probably a few other languages as well. But: it is not meaningfully correct code in many of the runtimes which implement that language. It was only valid in NodeJS after version 18, after all.
What you're really asserting is: Node is not a syntax. That's more accurate; but still inaccurate. Node does have its own syntax. For example; if you were to execute "await myFunc()" in NodeJS v6, you would get a syntax error. So, if Node isn't a syntax; what syntax does it use? JavaScript? By what definition? ECMAScript? Certainly a subset of the global standard, or a version of the standard released in the past. They're quite bad at keeping up. 99% syntactic compatibility with another syntax is still a different syntax; and thus it has its own syntax.
The old "you're writing HTML and CSS, that's not programming" runs in a similar vein. It is programming, by any reasonable definition of programming. You're instructing a computer to do something. The real assertion is that its not procedural programming; which seems like a pretty dumb differentiation to lose sleep over to me.