abelanger

9 ms·

61.
Automating multi-language SDK doc generation with testable code snippets(docs.hatchet.run)
1 points by abelanger 1y ago|0 comments
62.
by abelanger 1y ago
One thing I've been wondering recently: has the experience of using software (specifically web apps) been getting better? It seems like a natural extension of significantly increased productivity would lead to fewer buggy websites and
63.
by abelanger 1y ago
Agents depend heavily on the quality of their individual components, so it's pretty obvious that demo agents are going to be incredibly unstable. You need a success rate for each individual component to be near 100% or build in a mecha
64.
by abelanger 1y ago
(we haven't looked too deeply into agent-kit, so this is based on my impression from reading the docs) At a high level, in Pickaxe agents are just functions that execute durably, where you write the function for their control loop - wi
65.
by abelanger 1y ago
Definitely understand the frustration, the difficulty of Hatchet being general-purpose is that being performant for every use-case can be tricky, particularly when combining many features (concurrency, rate limiting, priority queueing, retr
66.
by abelanger 1y ago
Thanks! Would love to hear more about what type of agent you're building. We've heard pretty often that durable execution is difficult to wrap your head around, and we've also seen more of our users (including experienced eng
67.
by abelanger 1y ago
Thanks! Our favorite resources on this (both have been posted on HN a few times): - https://www.anthropic.com/engineering/building-effective-age... - https://github.com/humanlayer/12-factor-agents
68.
Show HN: Pickaxe – A TypeScript library for building AI agents(github.com)
70 points by abelanger 1y ago|26 comments
69.
The Lo-Fi Art and Human Tools Era(pketh.org)
3 points by abelanger 1y ago|0 comments
70.
Accounting for Elevation(busgraphs.com)
2 points by abelanger 1y ago|0 comments
71.
The Dangers of Numb Coding in the AI Era(articulatecode.dev)
2 points by abelanger 1y ago|0 comments
72.
by abelanger 1y ago
The primary difference is that Hatchet is an all-purpose platform for async jobs, so while durable execution is a pattern that we support, we have a lot of other features like concurrency and fairness control, event ingestion, custom queues
73.
by abelanger 1y ago
For an agent that executes locally, or an agent that doesn't execute very often, I'd agree it's arbitrary. But programming languages make tradeoffs on those very paths (particularly spawning child processes and communicating
74.
by abelanger 1y ago
Nice! It makes a lot of sense for orchestrating infra deployments -- we also started exploring Temporal at my previous startup for many of the same reasons, though at one level higher to orchestrate deployment into cloud providers.
75.
by abelanger 1y ago
I think there's a gap between people familiar with durable execution and those who use it in practice; it comes with a lot of overhead. Adding a durable boundary (via a task queue) in between steps is typically the first step, because
76.
by abelanger 1y ago
OP here - this type of "checkpoint-based state machine" is exactly what platforms which offer durable execution primitives like Hatchet ( https://hatchet.run/ ) and Temporal ( https://temporal.io/ ) a
77.
by abelanger 1y ago
This reads more like a pitch for open-source than anything else. > Switching out something, even if it's open source and self-hosted, means that you're rewriting a lot of code. The point of something open-source and self-hosted
78.
by abelanger 1y ago
I'm a big fan of https://github.com/humanlayer/12-factor-agents because I think it gets at the heart of engineering these systems for usage in your app rather than a completely unconstrained demo or MCP-based solu
79.
Go is a good fit for agents(docs.hatchet.run)
236 points by abelanger 1y ago|175 comments
80.
by abelanger 1y ago
> program building is an entropy-decreasing process...program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence > Only humans can de
81.
by abelanger 1y ago
Congrats on the launch! I have a few questions (though I know very little about this space): 1. How often is the cause of a denied insurance claim a documentation error vs an intentional denial from an insurance company (either an automated
82.
by abelanger 1y ago
> Most execution environments are stateful (e.g., they may rely on running Jupyter kernels for each user session). This is hard to manage and expensive if users expect to be able to come back to AI task sessions later. A stateless-but-pe
83.
by abelanger 1y ago
While we didn't look too closely into this, our buffers used to scale capacity based on a Fibonacci sequence if we hit capacity within the flush interval, up to a max capacity. I'm sure there's much better prior work on the i
84.
by abelanger 1y ago
With these queries, `session_busy_ratio` is just going to be 1, so it's most likely going to trivially evaluate to 14 assuming we're CPU bound on writes. It's slightly more interesting on real data, I just checked against one
85.
by abelanger 1y ago
> I cannot think of a situation where I could convince my team to allow 100k inserts to be pooled up waiting in memory for a process to crash or a deployment to wipe it out, but having a single buffer is also amazing mistake. io_uring is
86.
by abelanger 1y ago
OP here, I agree. The point of the article is both educational and also aims to set a lower bound on latency and an upper bound on throughput for Postgres writes, and see how these tradeoff under different circumstances. I tried to make the
87.
The fastest Postgres inserts(docs.hatchet.run)
59 points by abelanger 1y ago|25 comments
88.
The Time of Monsters(notesfromthecircus.com)
9 points by abelanger 1y ago|1 comments
89.
by abelanger 2y ago
Hey there - all of our self-hosting docs show you how to set up Postgres: https://docs.hatchet.run/self-hosting Would love to hear more about what you found confusing!
90.
by abelanger 2y ago
We actually have support for that, we just haven't migrated the doc over to v1 yet: https://v0-docs.hatchet.run/home/features/webhooks . We'll send a POST request for each task. > It is such a better s

More ›