Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Queues

deno.com

Post reply on HN
Print view View original

111–120 of 168 posts

Re: Deno Queues

#111

Post by 015a »

Aldipower wrote: post #69
015a wrote: post #50

Earlier quoted context omitted.

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 ju…

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.

[1] https://node.green/

Re: Deno Queues

#112

Post by simonw »

postalrat wrote: post #109
londons_explore wrote: post #101

Earlier quoted context omitted.

Is it not normally bad practice to have 2 tables with basically identical fields and move rows between them? Isn't that exactly what indexes were designed for?

If one table had millions of rows and the other only a few dozen and you are querying the few dozen often then it could make sense to have two tables. Different database treat indexes with sparse data differently.

Yeah, that seems like the reason for this design decision here. The queue_running table sits empty the majority of the time, very occasionally gaining a row or two just while they are being processed.

Re: Deno Queues

#113

Post by paulddraper »

ricardobeat wrote: post #92
locallost wrote: post #23

Earlier quoted context omitted.

How do you know it's a toy queue?

Presumably everything AWS offers is way more battle-hardened and with stricter SLOs just due to the sheer volume of their customers. But people are way too afraid of simple tech these days. If there aren’t dedicated QA and Ops teams, at least 2k GitHub stars, it’s not web-scale™ and meant to run on a fleet of 726 servers at minimum, it’s not to be trusted!

If it doesn't have 1k GitHub stars it's either trivial or it has high risk of bugs.

Re: Deno Queues

#114

Post by robertlagrant »

catlover76 wrote: post #49
robertlagrant wrote: post #44

Earlier quoted context omitted.

> 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

Sure - e.g. it comes with a web server built in, ready to make web apps with a quick Deno.serve. It's seems oriented in a certain direction.

Re: Deno Queues

#115

Post by billywhizz »

pests wrote: post #98

I feel its odd for a compiler/language toolchain to have a cloud offering. I understand the motivations but 20% of the article was about their Deno Deploy product and how to calculate API costs... I understand its only when using their cloud and there is a local implementation, but I just couldn't imagine using a feature in LLVM, for example, where if you were to upload the binary to a specific cloud it would use a d…

there is also a b2b game in play here by deno. i'd imagine a FaaS JS/TS only platform powered by Deno runtime is attractive to a lot of already existing web services who want to expose the ability to write webhooks/event-based functions in their service offerings?

https://deno.com/blog/netlify-edge-functions-on-deno-deploy

Re: Deno Queues

#116

Post by BoorishBears »

endisneigh wrote: post #110
dsherret wrote: post #71

Earlier quoted context omitted.

> 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-k…

This is not true, you cannot run your own foundationdb server and use the kv service without reimplementing yourself in fdb

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.

Re: Deno Queues

#117

Post by spion »

I like how updating the data and enqueueing a message can be part of a single transaction. That's indeed pretty powerful.

A bit of an aside, but not sure we want at-most-once delivery for email.

Re: Deno Queues

#118

Post by hintymad »

What happens to the mantra that "database as a queue is harmful"[1]? Of course Amazon teams internally use DynamoDB for all kinds of queues, which implies that we get to do a lot of things easily if we get a super robust storage solution. So, I guess the question is really whether FoundationDB can be used as a backend for queues.

[1] https://www.google.com/search?q=Use+database+as+a+queue+is+h...

Re: Deno Queues

#119

Post by bobbyi »

londons_explore wrote: post #101
simonw wrote: post #67

I dug into the internals of the local, SQLite version of this just now and wrote up some notes here: https://til.simonwillison.net/deno/deno-kv#user-content-deno... The most interesting detail is probably the schema they're using for that: CREATE TABLE queue ( ts integer not null, id text not null, data blob not null, backoff_schedule text not null, keys_if_undelivered blob not null, primary key (ts, id) ); CREATE TA…

Is it not normally bad practice to have 2 tables with basically identical fields and move rows between them? Isn't that exactly what indexes were designed for?

Materialized views handle this scenario, but sqlite doesn't have them

Re: Deno Queues

#120

Post by robertwt7 »

How is this different than using RabbitMQ? Can anyone tell me what’s the benefit of choosing this one over some other message queues or even kafka?
Post reply on HN