It’s similar in spirit to elm-procedure (making sequencing side effects nicer), but from my understanding the key differences are:
It performs sub-procedures sequentially (Procedure.map2 has similar behaviour to elm/core’s Task.map2)
If you’re using ports and you’re expecting a value on the other side you still have to wire together Commands and Subscriptions together via Procedure and Channel.
Whereas elm-concurrent-task:
Performs map2+ (and nested map2+) concurrently.
Is more oriented around a Request/Response style - i.e. call an external function an expect a value back (you can do this with Task in elm-procedure but you lose the concurrency bit).
My app uses TaskPorts, and I use packages that provide namespaced taskports. It’s not super clear to what extent I would have to ditch them or work around them if I want to migrate to this package. A guide on this would be awesome!
This is super exciting news, congrats on the release! Running a tree of Tasks concurrently sounds like a game-changer, especially for more complex applications. And the seamless integration with external JS is something that’s much needed in the Elm community.
Shoutout to @dillonkearns and @choonkeat for their contributions! Can’t wait to dig into elm-concurrent-task and see what it can do.