More SC and SP propaganda please

[goodboy]

I'm noticing a lot of new people first finding this project and asking me about all sorts of things related to future design and goals but it's clear they haven't read up on nor fully understand the concept in progress of structured concurrency (aka SC). I want to stick in the docs some more "required reading" that I can point to before hearing any thots that haven't been built with this knowlege a priori.

Here's a wip list that probably should be added:

• Nathaniel's original blog post
• Martin's blog post on SC in high level langs
• the SC forum
• the kickoff post by Martin in that forum

I also need to figure out a way to quickly explain that tractor is never going to be strictly a worker pool and that it's a lower level system on top of which you build such concurrency patterns. Likely requiring reading about zeromq versus amqp, something on erlang OTP. Linking to specific patterns in the zeromq guide is probably a good idea.

[ryanhiebert]

It might have headed my bugging you off if there were explicit mention that it doesn't really make sense for Tractor to be thought of as a replacement for Celery or other task runners. It's dealing at a significantly lower level that that kind of user library would be.

[goodboy]

@ryanhiebert hehe indeed, except bugging me off is impossible bruv :smile_cat:

it doesn't really make sense for Tractor to be thought of as a replacement for Celery or other task runners.

Yeah and I think a little excerpt that drives this home will likely be enlightening to new discovers of the project :sunglasses:

[goodboy]

Some interesting discussion on SC versus "actor models" in here: https://trio.discourse.group/t/sizing-the-channel-deadlock-freedom-vs-back-pressure/311

[ryanhiebert]

That is interesting, and the perspective makes sense to me. I love his intuition that programming with state machines is annoying for the same reasons that assembly is a pain in the butt.

ISTM that because of the necessity of communicating between devices, some semblance of an "actor" instead of preferring functions is inherent to the work of this package. I guess what I'd hope for thing package to be, and I'd be interested to know if this matches your intent, is a way to isolate the actor unintuitiveness of inter-process and inter-machine communication away, so that I can get back to my idealized structured concurrency way of thinking.

[goodboy]

@ryanhiebert checkout #18 as well if you're looking for a lot more in depth discussion on this; there's quite a good video from the original author of the actor model talking about pretty much all (and more) of these concepts. I link to a bunch of important parts in that issue.

A lot of the discourse I've heard on "actor models" is, frankly, just uninformed IMO.

So a lot of what you hear said fits with the idea that not a lot of people have read proper "actor model theory": they have incorrect assumptions about models due having not been exposed to the source and/or full extent of the underlying material.

ISTM that because of the necessity of communicating between devices, some semblance of an "actor" instead of preferring functions is inherent to the work of this package.

Yup, I would claim tractor is an actor model while not really looking like one from the outside. It fulfills the 3 axioms just fine and we'll show this whenever we get around to #17.