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