dangistan202611 2 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.

▲

icyfox 2 hours ago | parent | next [-]

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 2 hours ago \| parent [-]
		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. 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.

▲

9dev an hour ago | parent | prev [-]

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 a few seconds ago \| parent [-]
		Huh. There is nothing wrong with async, but if my code is sync, what am I to do?