Live data from Hacker News

Durable Coroutines for Go

github.com

21–30 of 37 posts

Re: Durable Coroutines for Go

#21
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 

Re: Durable Coroutines for Go

#23
post #21

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

It's a good point, but the entire program would have to be written this way (you can't use the standard library, or any other dependencies).

What if there were tools to inspect and debug the coroutine state? That's an area we're exploring now.

Re: Durable Coroutines for Go

#24

This seems really brittle. https://github.com/stealthrocket/coroutine/blob/main/getg_am...

Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "r…

You do what you have to do, but as a user, I like to know how things will break and what my options will be. I was curious how it worked, and took a peek at the first file that seemed it might reveal something interesting.

Re: Durable Coroutines for Go

#25

Earlier quoted context omitted.

You’re correct that code migration is still a to do, we’ll be exploring how to do that in the future. As you can imagine there are a lot of challenges with it, but ideas are welcome!

It seems like generating some data structure definitions (similar to a protobuf) and checking them in along with the code would be useful? Then the compiler can tell you when they still match, or you made an incompatible change to the code. This seems like a situation where defining the data structure in two different ways might be good?

This seems like a good use case for Cap'n Proto.

Re: Durable Coroutines for Go

#26
post #4

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 su…

An open-source version of this I made for Google Summer of Code 2005: https://sourceforge.net/projects/jauvm/

Re: Durable Coroutines for Go

#27

This seems really brittle. https://github.com/stealthrocket/coroutine/blob/main/getg_am...

Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "r…

They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.

Re: Durable Coroutines for Go

#29
post #27

Earlier quoted context omitted.

Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "r…

They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.

https://research.swtch.com/coro might be an interesting read.
Post reply on HN