Seems interesting, what are the plans on Rust SDK?
Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
51–60 of 102 posts
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#52Earlier quoted context omitted.
Chiming in as the founder of https://www.inngest.com . It looks like Hatchet is trying to catch up with us, though some immediate differences: * Inngest is fully event driven, with replays, fan-outs, `step.waitForEvent` to automatically pause and resume durable functions when specific events are received, declarative cancellation based off of events, etc. * We have real-time metrics, tracing, etc. out of the box in o…
Maybe let them have their launch? Mitchell said it best: https://x.com/mitchellh/status/1759626842817069290?s=46&t=57...
Ah, yes, fair. Someone (and I don't know who) mentioned our company so I did jump in... kind of fair, too. I'l leave this thread :)
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#53I 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 p…
> neither is adding Redis or RabbitMQ to our software stacks simply to support queue use cases
I disagree that "adding Redis to our software stack" to support a queue is problematic. It's a single process and extremely simple. Instead now with tools like this, you're clobbering up your database with temporal tasks alongside your operational data.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#54[dead]
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#55[dead]
What the f is this spam ?
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#56Being 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…
I’m also interested in understand the context for MIT instead of dual licensing for commercial needs, what’s the current best strategy ?
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#57I am surprised that there's still money for this type of OSS SaaS companies. Aren't all the money go to AI companies these days (even the unicorns didn't do well with their IPOs. E.g. Hashicorp). That said, I love every single addition to the Go community so thumbs up from me.
It does seem like some really great options are emerging in the Go community, and a lot of newer execution frameworks are supporting Go as one of the first languages. Another great addition is https://github.com/riverqueue/river.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#58What are some real world use cases you see customers using this for?
Folks are using us for long-lived tasks traditionally considered background jobs, as well as near-real-time background jobs. Our latency is acceptable for requests where users may still be waiting, such as LLM/GPU inference. Some concrete examples:
1. Repository/document ingestion and indexing fanout for applications like code generation or legal tech LLM agents
2. Orchestrating cloud deployment pipelines
3. Web scraping and post-processing
4. GPU inference jobs requiring multiple steps, compute classes, or batches
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#59Seems interesting, what are the plans on Rust SDK?
We'd like to stabilize our existing 3 SDKs and create a proper spec for future SDKs to implement. While we use proto definitions and openapi to generate clients, there are a lot of decisions made while calling these APIs that are undocumented but kept consistent between TS, Python and Go.
Once that's done and we consider our core API stable, there's a good chance we'll start tackling a new set of SDKs later this year.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#60I 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 p…
Yes, I remember reading the post and the discussion surrounding it being very high quality!
I particularly like the section on escape hatches - though you start to see the issue with this approach when you use something like Celery, where the docs and Github issues contain a number of warnings about using Redis. RabbitMQ also tends to be very feature-rich from an MQ perspective compared to Redis, so it gets more and more difficult to support both over time.
We'd like to build in escape hatches as well - this starts with the application code being the exact same whether you're on cloud or self-hosted - and adding support for things like archiving task result storage to the object store of your choice, or swapping out the pub/sub system.