[latchkey]

> what if it fails, or what if you're not sure about whether it failed?

This is covered in the GCP Tasks documentation.

> There's definite scaling benefits to throwing tasks into Google's limitless compute power, but there's a lot of cases where a smaller, more correct queue is plenty of power, especially where Postgres is already the database of choice.

My post was talking about what I would implement if I was doing my own queue, as the authors were. Not about using GCP Tasks.

[politician]

Do you know that brandur's been writing about Postgres job queues since at least 2017? Cut him some slack.

https://brandur.org/job-drain

https://news.ycombinator.com/item?id=15294722

[bgentry]

2015, even :) https://brandur.org/postgres-queues

[latchkey]

"I'm into effective altruism and created the largest crypto exchange in the world. Cut me some slack."

No, we don't operate like that. Call me out when I'm wrong technically, but don't tell me that because someone is some sort of celebrity that I should cut them some slack.

Everything he pointed out is literally covered in the GCP Tasks documentation.

https://cloud.google.com/tasks/docs/dual-overview

https://cloud.google.com/tasks/docs/common-pitfalls

[robertlagrant]

> No, we don't operate like that. Call me out when I'm wrong technically

You're being "called out" (ugh) incredibly politely mostly because you were being a bit rude; "tell me X without telling me" is just a bit unpleasant, and totally counterproductive.

> because someone is some sort of celebrity that I should cut them some slack.

No one mentioned a celebrity. You're not railing against the power of celebrity here; just a call for politeness.

> Everything he pointed out is literally covered in the GCP Tasks documentation.

Yes, e.g. as pitfalls.

[latchkey]

Sure, updated my comment to be less rude.

[politician]

Appreciated