bzurak

For those of you unfamiliar with Wool (which I'm assuming is most of you reading this), it's a distributed execution runtime for Python I've been working on that adds parallelism to Python's existing async primitives, allowing you to "await" CPU-bound logic without blocking the caller with a relatively simple service topology compared to some of the other distributed runtimes out there. Concerns like prioritization, queuing, and routing can be expressed in native Python, while Wool handles the inter-process/host transport.

This gist illustrates some of the trials and tribulations I went through while implementing a distributed context system for the runtime. Maybe some of you will find it (i.e., wool, the feature, or the lessons) useful, but in any case I enjoyed the process (I may be a masochist) and learned a lot.

I’m not sure why people are assuming I’m pushing for distributed OOP here. Wool is completely unopinionated about how you decide to architect your application - that’s the entire point.

So if you wanted to scale, say, a hyperparameter search across a cluster, what would you prefer?

I have a feeling people will begin to purposely use slightly incorrect grammar to give the impression they are indeed human in their writing.

Wasn’t previously aware of this opinion, but having read it, I can tell you I’m not actually committing this fallacy within the framework- I’m not forcing anyone into making their instance methods RPCs- I leave that up to my users. They are grown adults (presumably) and can commit whichever fallacies they desire.

Fair enough

I think LLMs are incredible tools that I will continue to use unapologetically, but I’m also very particular and not going to be putting my name to AI slop. Those are my genuine thoughts on the matter, they just happened to be cleaned up by an automated stochastic parrot.

Not on my watch

You mean the cadence where everything is presented in threes? Yeah I hate it too, but beats paying some blogger to do it

Sure, my argument is that those concerns should be composable with the distribution layer, not defined by it. There are plenty of different ways to pass data across a network or between machines, I'm not going to reinvent them all. There are also plenty of ways to manage non-transient errors (and very app-specific), I'm not going to implement them all. I'm also not assuming you need or want object persistence and replayability of your workflows. If you do, then use the right tool for the job.

I agree

Yeah but... who does that?

To be clear, not all of your coroutines become distributed. You explicitly declare what you want executed remotely, and you'll probably want your workers running in a VPC - it's just a nifty way of scaling your app horizontally without sinking too much effort into how you choose to define your distribution boundaries. It wouldn't be any different than scaling any other service horizontally using something like Kubernetes (which is probably how you'd manage wool workers as well).