| ▲ | Go-Native Durable Execution(dbos.dev) |
| 48 points by hmaxdml 5 days ago | 14 comments |
| |
|
| ▲ | erdaniels 5 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | eatonphil 2 hours ago | parent [-] | | A thing to note is that Restate is not open-source (BSL) while dbos (core, anyway) and temporal are. (Haven't heard of hatchet before.) 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. |
|
|
| ▲ | colek42 3 hours ago | parent | prev | next [-] |
| We love Dapr's durabletask-go. https://pkg.go.dev/github.com/dapr/durabletask-go |
| |
|
| ▲ | dangoodmanUT 5 hours ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | hmaxdml an hour ago | parent | next [-] | | 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 ;) | | |
| ▲ | dangoodmanUT 39 minutes ago | parent [-] | | Thanks, I didn't mean it as criticism, I guess my 5am brain thought the way it was worded almost came off as like "look at our unique idea" which was a pretty common pattern. |
| |
| ▲ | akahn 3 hours ago | parent | prev | next [-] | | > but they do write this like Temporal… doesn’t exist See "DBOS vs. other systems" on the github repository page[1] 1: https://github.com/dbos-inc/dbos-transact-golang?tab=readme-... | | | |
| ▲ | pphysch 2 hours ago | parent | prev [-] | | We bounced off dbos when we found they charge $$$ for their CRUD web GUI ("DBOS conductor"), which they also "strongly recommend" for production use, for good reason. | | |
| ▲ | hmaxdml an hour ago | parent [-] | | Conductor is about enterprise features like automatic workflow recovery, alerting, or RBAC. The GUI is a nice to have -- but all your workflow data are in Postgres. You can access it very easily. |
|
|
|
| ▲ | barelysapient 5 hours ago | parent | prev | next [-] |
| 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 |
|
| ▲ | sklarsa 5 hours ago | parent | prev [-] |
| Very timely for me! I've been looking into a go-based workflow engine. How does DagGo compare to go-workflows? https://cschleiden.github.io/go-workflows/ |
| |
| ▲ | atmonostorm 5 hours ago | parent [-] | | I landed up creating https://github.com/atmonostorm/derecho to answer the question of "in-process temporal.io". Works pretty well, with some unique features (error-controlled retry behavior) that temporal can't do. 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. |
|