It just uses native go function closure to hold and pass data among tasks, and it requires users to consider the data race problem. Cuz in some cases, tasks are executed in parallel.
Do you have an example of this done idiomatically? All the examples seem to be just printing, no passing any data between the nodes. That's not really a realistic scenario, since the main point of a flow graph in my experience is to compute stuff, and you typically need back pressure, queues, priorities etc. to solve real-world problems.
Very helpful, thank you. This also makes it apparent (it wasn't clear to me before) that each graph is declared alongside the data. You cannot reuse a graph to run multiple times on different data; you define the graph every time.
Yes. Data is attached to tasks via Go Native variable binding. Values are captured by task function once defined (closure). In some cases, You can change the value of the variable(like changing the value of ptr, rather than ptr itself) and rerun the whole graph to support your cases.
That's why I decided to support static graphs in the first place. After all, in most cases, static graph programming is enough, and being a user-friendly really matters.
This is a pitfall. I’m working on something similar (internal solution) and dynamic task graph bites back hard very quickly.
Domain I’m working on is very prone to a failure so having simple visualization/interaction (e.g. click to inspect/retry) is an important feature.
For that task graph needs to be resolved and static before actual execution phase. Nothing prevents multi-loop resolution (i.e. task graph which result is a task graph). Just make sure artifact sits in-between.
Agree. lightweight embedded libs like go-taskflow are used in a much different way compared to distributed workflow systems. Coders should be aware of the pros and cons of those repos or systems.
Not quite like although they may share some same concepts while using. go-taskflow is more like a lib or an embedded framework to organize task dependency and execute tasks in parallel rather than a platform.
A taskflow-like General-purpose Task-parallel Programming Framework with an integrated visualizer and profiler for Go, inspired by taskflow-cpp, with Go's native capabilities and simplicity, suitable for complex dependency management in concurrent tasks.
https://pkg.go.dev/github.com/noneback/go-taskflow