I 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 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
Sure, but genuine question: How easy it is to run my own infrastructure for Deno Queue, and, crucially, how can I know that it will still be as easy and transparent in 5 years from now when the VCs want to see some $$$. That the company developing Deno and the services that monetize Deno is the same is a major conflict of interest. And if history is of any guide, in the end economic incentives always win, no matter how good-hearted people are.
When imagining future scenarios, maybe don't get too fixated on one? Another possibility is that competitive service providers will implement the same services.
(It didn't really happen with App Engine, but this seems like a cleaner API?)
I guess I remembered it incorrectly? This looks pretty good:
> Deno KV databases are replicated across at least 6 data centers, spanning 3 regions (US, Europe, and Asia). Once a write operation is committed, its mutations are persistently stored in a minimum of two data centers within the primary region. Asynchronous replication typically transfers these mutations to the other two regions in under 10 seconds.
'.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 few examples where this is not the case (Javascript is definitely the best one; Java/JDK; python). There are hobbyist runtime re-implementations of some languages. But generally: Only academics worry about differentiating them.
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.
Node is a JavaScript runtime with some framework stuff on top. Not more, not less. The language is the implemented ECMAScript version. If you want to add a new (key)word to the language, there is a long commitment process.
"Fooloofol" will give `Uncaught ReferenceError: fooloofool is not defined` in English and Node. :-D
See, but this brings up an interesting point: What is JavaScript? The answer may surprise you: its the common parlance we very reasonably use to refer to the programming language where we can do things like `"\t" == 0" and get `true`. But, interestingly: Oracle owns the trademark on that name, and so in very few if any formal specifications or standards bodies will you find the name "JavaScript"; its "ECMAScript".
But, ok: Node advertises itself as a Javascript runtime, but the standards body against which they are tracking makes it an ECMAScript runtime; not more, not less. Probably not more, I'll grant you; but certainly less! You can pick any formally standardized version of ECMAScript, and find that Node.js has incomplete support, in some cases even for years after publication [1]. Again; its close enough nowadays, especially outside of ESNext which really doesn't count, that we're not talking about a useful or meaningful difference; but rather a pedantic difference.
"Languages" formally specified independent of implementation are not languages. Language is the implementation; and the specification guides it. I'm not just talking about programming languages. I'm talking about spoken and written language as well.
For lack of a better specification; The Oxford English Dictionary is not English. The dictionary is both more and less than english. It has a very large center-of-the-venn-diagram. But: commonly spoken English words will always exist for which it doesn't yet have definition for (it's as of yet blissfully unaware of "bussin" and "rizz"). Simultaneously; it will have words that make no sense to modern speakers, or definitions that have fallen out of use.
It's the same situation with programming languages; the language is the implementation. The specification, if one exists, guides the implementation; but without absolutely no-more-no-less 100% coverage of the specification (which has not happened in NodeJS), and absolutely no-ambiguity-in-the-spec (which has never happened in any formal specification), they are meaningfully and inherently different. Because zero-ambiguity is impossible given fundamental constraints in politics, communication, and in a very real way physics: the specification isn't the language.
Here's an interesting fun fact: TypeScript; that programming language we all love. It has no formal specification. Yup! People have been asking Microsoft since 2016, when they last published the specification, to update it, but the team has (explicitly or not, I don't know) taken the stance that the implementation (and its test cases) are the specification. The language is the implementation.
So; what language is Deno-compatible code written in? The only accurate, formal, academic, correct answer is: Its written in Deno. The language is the implementation. Productively and usefully; its written in a language that is approximately similar enough to TypeScript that no one will notice.
Modern ECMAScript implementations are a superset of the JavaScript language.
Look, taking your spoken language analogy, things like the Deno KV store are an implementation of instructions doing something specific. In spoken/written language this could be a cooking receipt. Of course the receipt is not a language in itself, expect cooking is your language, haha, but it is written _in_ a language. You would never title a cook book a language.
I agreed with it until you injected the irrelevant bit about HTML and CSS being programming languages. It is ARGUABLE true, but very unhelpful, you are not giving learners useful direction when you use a blanket term ("programming language") to refer to vastly different things that require different mindsets (js & other languages vs html, css, yml...) to master.
> 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.
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 Deploy.
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.
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 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