4 ms·

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

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

akahn 7mo ago
> 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-ov-file#dbos-vs-other-systems https://github.com/dbos-inc/dbos-transact-golang?tab=readme-...
- dangoodmanUT 7mo ago
  I was referring to this post
pphysch 7mo ago
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 7mo ago
  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.
  - pphysch 7mo ago
    The offering would be enticing if some Web GUI features were behind a paywall. Separate "production" from "enterprise". 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.
hmaxdml 7mo ago
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 7mo ago
  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.
- dangoodmanUT 7mo ago
  In review, I think it might have been the workflow versioning being strange, and the lack of any heartbeating/crash detection for longer running activities
  - hmaxdml 7mo ago
    Automatic crash detection for your process is built-in our Conductor offering. The library has a default recovery mode when used standalone. 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 https://github.com/dbos-inc/dbos-transact-py/pull/598

akahn 7mo ago

> 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-ov-file#dbos-vs-other-systems https://github.com/dbos-inc/dbos-transact-golang?tab=readme-...

dangoodmanUT 7mo ago
I was referring to this post

pphysch 7mo ago

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 7mo ago
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.
- pphysch 7mo ago
  The offering would be enticing if some Web GUI features were behind a paywall. Separate "production" from "enterprise". 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.

hmaxdml 7mo ago

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 7mo ago
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.
dangoodmanUT 7mo ago
In review, I think it might have been the workflow versioning being strange, and the lack of any heartbeating/crash detection for longer running activities
- hmaxdml 7mo ago
  Automatic crash detection for your process is built-in our Conductor offering. The library has a default recovery mode when used standalone. 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 https://github.com/dbos-inc/dbos-transact-py/pull/598