Similar in what way:
- Tower allows you to compose the calls with, essentially, helpers, and express your decisions on how to apply retries and timeouts concisely.
- Waymark also allows you to express your decisions on retries and timeouts via compact declarations.
The difference is, though, that with tower you provide the execution, while with waymark the execution is handled by waymark itself. So, this becomes more like tower+tokio::spawn, except this is not even the key thing waymark does.
The main feature is, speaking in rust analogy terms, that we convert workflow into a future, and not just any future, but a future that can be serialized and stored in postgres; then we run it to completion, and if anything crashes we can resume on a new node from the state that was last persisted.
Persistence is automatic and happens on any "external input" that the internal VM absorbs (typically the result of a side effect like an action execution).
So, while tower can, in principle, add persistency to your call (and does handle timeouts and retries already) - it doesn't handle the orchestration of the whole program in the same way waymark does.
One more difference: waymark is written in rust, but you don't write in rust (yet) when using it. You have to write the code in Python (now) and we'll be adding more supported languages later. Rust is obviously on our list too - but we'd want to prioritize based on the demand.