8 comments

[ 0.33 ms ] story [ 41.4 ms ] thread
After spending way too much time debugging runtime problems with python based workflow tools, I’ve been implementing something very similar: DagGo.

DagGo is a type based workflow tool with observably written in Go. Jobs are compile time safe. I’m planning to bring it to feature parity with tools like Dagster over the next few months.

https://github.com/swetjen/daggo

Also check out https://www.restate.dev/. We chose this internally after evaluating it against temporal, hatchet, and dbos. The docs are pretty good and development locally and deployment to k8s was simple.
Been eager for something that wasn’t temporal (egregious overhead and annoying multiple services), but they do write this like Temporal… doesn’t exist. They use a lot of the same pioneered techniques (like “our own context type”) that they do.

go-workflows has always been the good alternative, but I’m sure dbos is a bit better supported. Dbos always had some weird gaps (I don’t remember why exactly, I just remember saying “oh well I can’t use this then” more than once), but maybe they’ll close them with the go sdk

Thanks for the comment (author here). I wanted this post to focus on the Golang specific implementation, not dwell on the durable execution ecosystem at large.

With respect to context, I don't know that anyone invented "having their own context". Go interface are extendable and pretty much every major framework I know of implement their own context.

Would love to learn more about the gaps that offset you. We're constantly improving here ;)

It looks like its just a copy and paste from temporal workflow go-sdk