The saved coroutine state is an implicitly-defined data structure and they don’t support any kind of migration when the code changes, so the durability will be quite limited.
This seems really brittle.
https://github.com/stealthrocket/coroutine/blob/main/getg_am...
I feel like once serializing god-knows-what state across program invocations is a requirement, I'd much prefer writing this explicitly so I can at least have a chance of debugging it
type Task struct {
I int
}
func (t *Task) Next() (bool, int) {
if t.I < 3 {
return t.I++, true
}
return 0, false
}
var t Task
t.Next()
json.Marshal(t)A succinct explanation of how durable coroutines are different (in practice) from Temporal would be useful.
From a user perspective: how is this different than what Temporal provides?
nice, but i had a separate idea.
what if u build a wasm runtime that can save and restore memory with and execution states, sounds much more full proof. or i might have misunderstood this idea :D.
Why are channels insufficient for this use case?
Why not fork Go and implement this directly? (and also removing any telemetry Google might have installed while at it...)
This is the kind of thing you can only trust the compiler to do. And we already have goroutines.
very cool - looking forward to seeing the rest.
Impressive work. This reminds me of an experimental JVM that was around about 20 years ago from a group called Velare. They could do durable coroutines just like this, but by throwing a particular exception rather than using `yield`. They also could return a value and allow the coro to be resumed with a value.
edit: here it is https://dl.acm.org/doi/10.1145/949344.949362 It was a built-in bytecode interpreter with suspendable threads
It changed significantly how you think about cooperating processes. It was like watching 2 processes have a conversation with each other without the controlling code getting involved in any way. Also, if you save the coros after each call, you can get step-by-step replays which are very helpful in debugging.