Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go-Native Durable Execution

dbos.dev

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Go-Native Durable Execution

#11

Post by eatonphil »

erdaniels wrote: post #4

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.

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.

Re: Go-Native Durable Execution

#12

Post by pphysch »

dangoodmanUT wrote: post #5

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 s…

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.

Re: Go-Native Durable Execution

#14

Post by hmaxdml »

pphysch wrote: post #12
dangoodmanUT wrote: post #5

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 s…

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.

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.

Re: Go-Native Durable Execution

#15

Post by hmaxdml »

dangoodmanUT wrote: post #5

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 s…

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 ;)

Re: Go-Native Durable Execution

#16

Post by dangoodmanUT »

hmaxdml wrote: post #15
dangoodmanUT wrote: post #5

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 s…

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 const…

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.

Re: Go-Native Durable Execution

#17

Post by pphysch »

hmaxdml wrote: post #14
pphysch wrote: post #12

Earlier quoted context omitted.

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.

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.

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.

Re: Go-Native Durable Execution

#18

Post by dangoodmanUT »

hmaxdml wrote: post #15
dangoodmanUT wrote: post #5

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 s…

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 const…

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

Re: Go-Native Durable Execution

#20

Post by hmaxdml »

thealish wrote: post #19

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

I notice you didn't provide any specific comparison alongside that comment, which makes me feel frustrated because I think the Temporal workflow SDK is very different. Architecturally, Temporal and DBOS are at two opposites of the durable execution spectrum. I'd love to understand what makes you think this work is a mere copy and paste. Would you be willing to share some more with me?
Post reply on HN