zlacker

>>InitEn+(OP)
How does it compare to something like apache airflow? I like the native Go integration, and that it is specifically mentioned that the overhead is minimal to start a job. Airflow can take quite a varying amount of time to schedule your job.

>>SPasca+IR
Passing information between steps is a pain in Airflow (https://docs.astronomer.io/learn/airflow-passing-data-betwee...) whereas it's quite trivial in windmill, the performances/latency is better, and it supports typescript. Overall, the biggest improvement is the support for typescript/go/bash and the low-code builder that will allow you to build extremely complex flows that would be hard to visualize with just code annotations but with exactly the same featureset and more (retries, error handlers, suspend/sleep). We also make it really easy to test individual steps and the whole flow since web apps allow you to build advanced UX fit for big graphs. But Airflow is a great framework that we took a lot of inspiration from.

>>rubenf+AS
From that link

    print_the_cat_fact(get_a_cat_fact())

Doesn’t seem like a big pain?

Looks like that page overcomplicate it by describing every underlying layer and old history of it.

>>Too+rA1
That's because you're looking at the TaskFlow syntax and a trivial example of passing all the results from a Task A as all the inputs of a Task B that follows it immediately. TaskFlow works mostly in trivial case. The true syntax for it is in the tab "Traditional syntax". For a complex graph where you're passing data from step A to a node that is far down the tree and deeply nested and you will see that it's quite cumbersome. Even in their trivial example:

    res = requests.get(url)
    ti.xcom_push(key="cat_fact", value=json.loads(res.text)["fact"])

    ...
  
    cat_fact = ti.xcom_pull(key="cat_fact", task_ids="get_a_cat_fact")