Live data from Hacker News

Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

news.ycombinator.com

11–20 of 102 posts

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#11
Interesting and congrats on the launch!

I am definitely a fan of all things postgres and it's great to see another solution that uses it.

My main thing is the RabbitMQ dependency (that seems to be a topic of interest in this thread). Getting rid of that and just depending on PG seems like the main path forward that would increase adoption. Right now I'd be considering something like this over using a tool like Rabbit (if I were making that consideration.)

You also compare yourself against Celery and BullMQ, but there is also talk in the readme around durable execution. That to me puts you in the realm of Temporal. How would you say you compare/compete with Temporal? Are you looking to compete with them?

EDIT: I also understand that Rabbit comes with certain things (or rather, lacks certain things) that you are building ontop of, which is cool. It's easy to say: why are you using rabbit?? but if it's allowing you to function like it with new additions/features, seems like a good thing!

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#13
Hey, this is Gabe from zenfetch. Been following you guys for a few months now since your first launch. I definitely resonate with all the problems you've described regarding celery shortcomings / other distributed task queues. We're on celery right now and have been through the ringer with various workflow platforms. Only reason we haven't switched to Hatchet is because we are finally in a stable place, though that might change soon in which case I'd be very open to jumping ship.

I know a lot of folks are going after the AI agent workflow orchestration platform, do you see yourselves progressing there?

In my head, Hatchet coupled with BAML (https://www.boundaryml.com/) could be an incredible combination to support these AI agents. Congrats on the launch

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#14
Being MIT licensed, does that mean that another company could also offer this as a hosted solution? Did you think about encumbering with a license that allowed commercial use, but prohibited resale?

Also, somewhat related, years ago I wrote a very small framework for fan-out of Django-based tasks in Celery. We have been running it in production for years. It doesn't have adoption beyond our company, but I think there are some good ideas in it. Feel free to take a look if it's of interest! https://github.com/groveco/django-sprinklers

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#15

Earlier quoted context omitted.

We're using RabbitMQ for pub/sub between different components of our engine. The actual task queue is entirely backed by Postgres, but things like streaming events between different workers are done through RabbitMQ at the moment, as well as sending a message from one component to another when you distribute the engine components. I've written a little more about this here: https://news.ycombinator.com/item?id=396439…

Do you find it frustrating that what people basically want is: (1) you, for free (2) develop all the functionality of RabbitMQ as a Postgres extension with the most permissive license (3) in order to have it on RDS (4) and never hear from you again? This is a colorful exaggeration. But it’s true. It is playing out with the pgvecto-rs people too. People don’t want Postgres because it is good. They want it because it i…

So true.

The advice of "commoditize your complements" is working out great for amazon. Ironically, AWS is almost a commodity itself, and the OSS community could flip the table, but we haven't figured out how to do it.

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#17
I love seeing commercial activity around using Postgres as a queue. Last year I wrote a post titled "Choose Postgres queue technology" that spent quite a bit of time on the front page here. I don't think it's likely that my post actually sparked new development in this area, but for the people who were already using Postgres queues in their applications, I hope it made them feel more comfortable talking about it in public. And I've seen a notable increase in public discussions around the idea, and they're not all met with derision. There's long been a dogma around Postgres and relational databases being the wrong tool for the job, and indeed they are not perfect, but neither is adding Redis or RabbitMQ to our software stacks simply to support queue use cases. Kudos to the Hatchet team! I hope you all find success.

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#19

Earlier quoted context omitted.

We're using RabbitMQ for pub/sub between different components of our engine. The actual task queue is entirely backed by Postgres, but things like streaming events between different workers are done through RabbitMQ at the moment, as well as sending a message from one component to another when you distribute the engine components. I've written a little more about this here: https://news.ycombinator.com/item?id=396439…

Do you find it frustrating that what people basically want is: (1) you, for free (2) develop all the functionality of RabbitMQ as a Postgres extension with the most permissive license (3) in order to have it on RDS (4) and never hear from you again? This is a colorful exaggeration. But it’s true. It is playing out with the pgvecto-rs people too. People don’t want Postgres because it is good. They want it because it i…

At least pgvector is financially supported by AWS.

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#20
post #13

Hey, this is Gabe from zenfetch. Been following you guys for a few months now since your first launch. I definitely resonate with all the problems you've described regarding celery shortcomings / other distributed task queues. We're on celery right now and have been through the ringer with various workflow platforms. Only reason we haven't switched to Hatchet is because we are finally in a stable place, though that m…

Hi Gabe, also Gabe here. Yes, this is a core usecase we're continuing to develop. Prior to Hatchet I spent some time as a contractor building LLM agents where I was frustrated with the state-of-tooling for orchestration and lock in of some of these platforms.

To that end, we’re building Hatchet to orchestrate agents with features that are common like streaming from running workers to frontend [1] and rate limiting [2] without imposing too many opinions on core application logic.

[1] https://docs.hatchet.run/home/features/streaming [2] https://docs.hatchet.run/home/features/rate-limits

Post reply on HN