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

151–160 of 168 posts

Re: Deno Queues

#151

Post by gabeidx »

simonw wrote: post #86

Unless I'm missing something, it looks like each Deno.openKv() instance only gets a single queue. For the local version you could get multiple queues by calling Deno.openKv("db-2.db") with different SQLite file paths each time, but that feels like a lot of overhead for a pretty common need. I guess this is a Deno architectural style thing - maybe when you build complex apps on Deno it's expected that you'll have a mi…

You are right, there's only a single queue at the moment.

One of the core devs has confirmed this on their discord: https://discord.com/channels/684898665143206084/115671428253...

Quoting here:

> Correct. Currently a single queue is supported. You could multiplex multiple types of messages on the single queue though.

Re: Deno Queues

#152

Post by asim »

leptons wrote: post #80
asim wrote: post #20

Earlier quoted context omitted.

Many people don't have experience with AWS or SQS and even those that do will still need to think about it. Deno is taking a batteries included approach which means the Dev can just import something and go. If someone provided equivalent libraries for the cloud then I'm sure people would adopt them. In the case of Deno I'm sure they've identified a common problem many Devs in their ecosystem have and are tackling it…

If Deno is only going after amateur devs by implementing simplistic features like this, then it will remain an amateur product. AWS/SQS may seem complex to some, but they are very powerful. Maybe Deno is doing what Apple did in the 80's by putting free Apple computers in classrooms - try to get new users hooked into their system and then they'll use it for life. Anyone doing anything serious with cloud computing is a…

AWS was a toy in 2006. No one in their right mind was switching to the cloud back then. We laughed at it. It took years to mature. I'd say things that look like toys today will be the dominant platforms of the future because generationally a 20 something person out of college is more likely to adopt it than use the overwhelming and complex AWS. Barriers to entry are something you have to consider. Meaning, many of us grew up in an era of transition from bare metal to cloud and we became early adopters of it. These new tools are the same for a younger generation.

Re: Deno Queues

#153

Post by endisneigh »

rprwhite wrote: post #144
endisneigh wrote: post #110

Earlier quoted context omitted.

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

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. [1] https://github.com/losfair/mvsqlite

That is not the same thing, still. Like you said it would be a reimplementation, not the same thing.

Re: Deno Queues

#154

Post by tmikaeld »

baq wrote: post #148
tmikaeld wrote: post #29

Why not instructions on how to use it with FoundationDB so that we can host it on our company infrastructure?

How do you think they make money?

It's MIT licensed, if anyone wanted to do that they'd just patch deno with it anyway.

Re: Deno Queues

#155

Post by BoorishBears »

antod wrote: post #94
marmaduke wrote: post #53

Earlier quoted context omitted.

I don't recall SQS taking anytime to set up queues, at least when using Celery (python task queue). IIRC you just name it in your code and use it.

That's just at the codebase end of it. But at the infra end of it, it's a different story. AWS is suited towards a very different scale of development effort than Deno currently is. The effort required from scratch to securely and reliably get to a point where a dev can just name a queue is substantial in AWS. You really need account hierarchies, guard rails, roles, permissions, delegated IaC etc etc in place to be a…

You can use libraries like SST and make it a few lines of code.

Re: Deno Queues

#156

Post by Aldipower »

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

Earlier quoted context omitted.

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". Bu…

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.

Re: Deno Queues

#157

Post by spion »

crabmusket wrote: post #122
spion wrote: post #117

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.

Didn't the article say at-LEAST-once?

Yeah it did. My bad writing "at most". But the problem is with "at least once" (email sending cannot be made idempotent AFAIK)

Re: Deno Queues

#158

Post by dackerlunghack »

meowtimemania wrote: post #103
dackerlunghack wrote: post #91

With grand promises rode the ploy Venture capital, ahoy! We make a lovable product to capture audience Vendor lock them at the earliest convenience Hey look at our awesome developer experience Add ANSI and emojis and comments saying it’s genius Some next level tech, plebs just don’t get it Next round of funding, we’ve already spent it I took the big dough, got puppets and framed it R-O-I is bad though but layoffs gon…

chat gpt?

    Human brains proudly present
    Real poetry? Grouchy resent!
    My rhyme is not gradient descent
    After all, it is barely nascent

Re: Deno Queues

#159

Post by frenchyatwork »

giovannibonetti wrote: post #136
postalrat wrote: post #109

Earlier quoted context omitted.

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.

Partial indexes solve exactly this problem. You add a WHERE condition that restricts the index to a subset of the whole table.

Partial indexes are still slower, the database needs to scan the index, and then look for the data, and data is less likely to appear in the same pages.

Re: Deno Queues

#160

Post by leptons »

asim wrote: post #152
leptons wrote: post #80

Earlier quoted context omitted.

If Deno is only going after amateur devs by implementing simplistic features like this, then it will remain an amateur product. AWS/SQS may seem complex to some, but they are very powerful. Maybe Deno is doing what Apple did in the 80's by putting free Apple computers in classrooms - try to get new users hooked into their system and then they'll use it for life. Anyone doing anything serious with cloud computing is a…

AWS was a toy in 2006. No one in their right mind was switching to the cloud back then. We laughed at it. It took years to mature. I'd say things that look like toys today will be the dominant platforms of the future because generationally a 20 something person out of college is more likely to adopt it than use the overwhelming and complex AWS. Barriers to entry are something you have to consider. Meaning, many of us…

> overwhelming and complex AWS

Any other systems a "20 something person" would cobble together for an app of any complexity from "toys" of today would be a complex web of half solutions. They'd be trying to do the same stuff that can be done within AWS, and often what they cobble together would be worse off having it made of disparate components from maybe dozens of different vendors. I can't see how it's any easier to connect all those dots than it is to do it within AWS. If you're new and doing simple stuff on simple systems that's all well and good, but don't expect it to scale easily or at all, and if you try you're in for a whole lot of dev-ops and networking and other bullshit just to get things to talk to each other. There's a lot less of that in AWS. Usually you just copy an ARN and paste it into another box, and the things are connected.

>Barriers to entry are something you have to consider.

There's no barrier to entry for AWS, unless you can't afford $0 per month. Anyone can sign up and use free services, and they are very well documented. There's tutorials galore, probably more than any other current toy platform(s). There's tools and tooling and all kinds of support out there for it. But sure, some toy platform might be more fun to use for your hello-world task tracking app if you aren't building anything serious.

Post reply on HN