Show HN: I built Wool, a lightweight distributed Python runtime(github.com)
github.com
Show HN: I built Wool, a lightweight distributed Python runtime
https://github.com/wool-labs/wool
6 comments
The payments background makes total sense as an origin for this I've seen teams reach for Ray or Prefect and spend weeks configuring things they didn't need, when the actual problem was just 'how do I get work off this one machine cleanly.
One thing I'm curious about: what happens when a gRPC worker goes quiet mid execution?
Does the caller find out, or is it purely fire and forget? I hit a similar decision point building a memory layer for AI agents ended up skipping retry logic entirely because the coordination overhead just wasn't worth it for my use case. Wondering if you landed in the same place or have a different take.
Sub-millisecond dispatch locally is a good sign. The number I'd really want to see is how that holds up once you've got 20-30 workers in the mesh that's usually where the interesting degradation starts.
One thing I'm curious about: what happens when a gRPC worker goes quiet mid execution?
Does the caller find out, or is it purely fire and forget? I hit a similar decision point building a memory layer for AI agents ended up skipping retry logic entirely because the coordination overhead just wasn't worth it for my use case. Wondering if you landed in the same place or have a different take.
Sub-millisecond dispatch locally is a good sign. The number I'd really want to see is how that holds up once you've got 20-30 workers in the mesh that's usually where the interesting degradation starts.
If you've worked with frameworks like Ray or Prefect, you're probably familiar with the promise of going from script to scale in two lines of code (or something along those lines). This is essentially the solution I was looking for: a framework with limited boilerplate that facilitated arbitrary distribution schemes within a single, coherent codebase. What I was hoping for, though, was something a little bit more focused - I wasn't working on ML pipelines and didn't need much else other than the distribution layer. This is where Wool comes in. While it's API is very similar to those of Ray and Prefect, where it differentiates itself is in its scope and architecture.
First, Wool is not a task orchestrator. It provides push-based, best-effort, at-most-once execution. There is no built-in coordination state, retry logic, or durable task tracking. Those concerns remain application-defined. The beauty of Wool is that it looks and feels like native async Python, allowing you to use purpose-built libraries for your needs as you would for any other Python app (with some caveats).
Second, Wool was designed with speed in mind. Because it's not bloated with features, it's actually pretty fast, even in its current nascent state. Wool routines are dispatched directly to a decentralized peer-to-peer network of gRPC workers, who can distribute nested routines amongst themselves in turn. This results in low dispatch latencies and high throughput. I won't make any performance claims until I can assemble some more robust benchmarks, but running local workers on my M4 MacBook Pro (a trivial example, I know), I can easily achieve sub-millisecond dispatch latencies.
Anyway, check it out, any and all feedback is welcome. Regarding docs- the code is the documentation for now, but I promise I'll sort that out soon. I've got plenty of ideas for next steps, but it's always more fun when people actually use what you've built, so I'm open to suggestions for impactful features.
-Conrad