Why don't all backend runtimes/frameworks fundamentally start with a queueing system?
Start with a persistent queue as source of truth. all computation is done in workers that pop off a queue and/or add to it.
Has this been tried and failed somehow? is this like Elixir?
Conversation
Trying this now with :)
PSA even though you start with a queue you can still block until your work is done, aka "synchronous start" of a workflow
Quote Tweet
I'm excited to finally share why I've joined @temporalio as Head of Developer Experience!
Here's my explainer on 3 core opinions of Temporal, why they're hard to do well, and the business opportunities it presents:
swyx.io/why-temporal/
Show this thread
1
7
you mean CPS? continuation passing? if so then no... just `await` an `async` workflow and the framework handles the "blocking"
1
I was going to ask about CSP as well.
Communicating sequential processes — it’s the PL idea that underpins Go and Erlang/Elixir.
Ah. I couldnt find a very good definition of CSP in Go (the go docs are way too brief) but yes - we have Signals and Queries docs.temporal.io/docs/go/signal
i was also referring to "synchronous" started workflows, which solve a concern people had for queue-first systems like i proposed
1
1
Show replies