Comment by dangistan202611

20 hours ago

It is too async heavy as per its readme -- this is very off-putting. Not everyone cares for async. There is no usage shown with sync code.

6 comments

dangistan202611

Reply
icyfox  20 hours ago

MIT licensed, just clarified in the repo.

As for async - background jobs are better modeled as async because of their natural parallelism across nodes imo. Logic in actions themselves are free to be as synchronous as you want. Why the preference?

  • dangistan202611  20 hours ago

    I dispute the "better" assertion. Anyhow, I don't know how familiar or not you are with sync code, but it fully supports background jobs using queues with threads/interpreters/processes. It has been around for decades, far longer than async.

    Also, it is okay to run something in the foreground. Not everything needs to run in the background. Sometimes it's better to wait and have assurance of completion.

    There is no natural parallelism of async code in Python. The coroutines run in a single thread.

9dev  19 hours ago

I don’t understand these kinds of strong emotions async python triggers in some people. It reminds me of the irrational hate towards systemd in the Linux world.

This is a platform for running workflows distributed on multiple machines, sometimes long-running and with lots of IO. Every single contender in the space advertises the same code, from temporal to hatchet to dagster. Because it makes sense to write it this way.

  • dangistan202611  18 hours ago

    Huh. I hate neither async nor systemd. There is nothing wrong with async, but if my code is sync, what am I to do?

    Also, the claim made that something is "better modeled as async" is wholly unqualified.