On the other hand, durable execution in dbos is implemented in libraries so you have different features for different languages (the Go one doesn't support SQLite as a backend for example while the Python one does), whereas Temporal and Restate are not embedded like this.
I've used it pretty heavily in production, ~30m workflows of various types from various projects through it at this point. No capacity to support it as OSS though, and my internal persistence backend isn't easily extricable from monorepo, but it's just an interface with conformance tests.
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
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 ;)
What do you find strange with workflow versioning? Would love to consider improving the semantics. In fact, we started doing it: https://github.com/dbos-inc/dbos-transact-py/pull/598
Right now the messaging is "you shouldn't use DBOS for production unless you are a paying customer", which is odd considering durable execution itself is a production-level concept. So we rolled our own in a few hundred lines of Python.
See "DBOS vs. other systems" on the github repository page[1]
1: https://github.com/dbos-inc/dbos-transact-golang?tab=readme-...
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.