icyfox - you should answer sir, not downvote when you dont have answer. It’s ok to accept when you are not aware about those AI scenarios, we can talk and build better. But please don’t misuse your 500+ karma.
Workflow definitions looks similar to Temporal, by design. They want you to program in your native code and separate actions at boundaries - as do we. A few fundamental differences -
1. Temporal gets its durable execution properties by booting up a full interpreter (Python/JS/etc) just to replay the previous state of your workflow. This requires your full logic to be deterministic because it's actually re-serializing variables from the cached state of the action outputs.
Waymark by contrast does everything by compiling your run definitions. This allows your logic to be nondeterministic as long as it implements the supported control flow. This compiled representation is also executed in our Rust VM core, so it's easily parallelizable to your whole machine.
As an aside - the Temporal maintainers also have to re-implement async handling in each of their supported languages. They have a rust core iirc but because they actually hook into the native language, they need to implement their own async abstraction. There are a lot of footguns with these implementations that they need careful handling to avoid. Since we share the same workflow VM runner against all languages we anticipate being able to add language support and keep it maintained much easier.
2. Due to this compilation, it's easier to catch errors locally and in CI before it reaches production. There's no notion of 'workflow changed' / incompatibility errors with future waymark workflows.
3. We have a simpler hosting paradigm. Instead of needing a full broker that you need to scale separately, we use Postgres as the only external service required. You can leverage your existing database expertise instead of needing to move all the knobs and dials of Temporal/RabbitMQ/etc.
[–] mukeshsinghnyc 4 hours ago
[–] icyfox 3 hours ago
Workflow definitions looks similar to Temporal, by design. They want you to program in your native code and separate actions at boundaries - as do we. A few fundamental differences -
1. Temporal gets its durable execution properties by booting up a full interpreter (Python/JS/etc) just to replay the previous state of your workflow. This requires your full logic to be deterministic because it's actually re-serializing variables from the cached state of the action outputs.
Waymark by contrast does everything by compiling your run definitions. This allows your logic to be nondeterministic as long as it implements the supported control flow. This compiled representation is also executed in our Rust VM core, so it's easily parallelizable to your whole machine.
As an aside - the Temporal maintainers also have to re-implement async handling in each of their supported languages. They have a rust core iirc but because they actually hook into the native language, they need to implement their own async abstraction. There are a lot of footguns with these implementations that they need careful handling to avoid. Since we share the same workflow VM runner against all languages we anticipate being able to add language support and keep it maintained much easier.
2. Due to this compilation, it's easier to catch errors locally and in CI before it reaches production. There's no notion of 'workflow changed' / incompatibility errors with future waymark workflows.
3. We have a simpler hosting paradigm. Instead of needing a full broker that you need to scale separately, we use Postgres as the only external service required. You can leverage your existing database expertise instead of needing to move all the knobs and dials of Temporal/RabbitMQ/etc.