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.
Consider a microservices architecture (for the sake of example), where a user sign up needs to create an account in three services: auth-svc, avatars-svc and emails-svc.
Your options to do it are either an event-sourcing architecture where your services have to orchestrate together via somewhat-awkward message-passing, or write another reconciling service where you write the logic more-or-less directly, but with a ton of code-overhead to make the execution reliable.
Waymark would help with the second approach, because it soaks in all the durable execution complexity, and gives you a way to just write the logic code and handle the edge cases - with a fraction of the code and systems you'd need otherwise.
I'd even dare to say - a tool like waymark, the second approach is pretty much impractical altogether, hence why the event sourcing microserivce architectures dominate today.
But, yet again, that's just one example of where waymark would be useful. If you can write the code where you can split the orchestration logic from the execution of the individual side effects - then with waymark your orchestration code can be just the logic you need, without the extra steps to persist the progress - thus making it easier to reason and mental model simpler.