[djha-skin]

I thought that the entire point of green threads was so that I didn't have to use something like Python's `yield` keyword to get nice, cooperative-style scheduling.

I thought go's `insert resumes at call points and other specific places` design decision was a very nice compromise.

This is allowing access to more and more of the metal. At what point are we just recreating Zig here? What's next? An optional garbage collector?

[wahern]

yield and resume here aren't keywords, they're regular variables (referencing regular closures) given those names purely for pedagogical purposes.

The only odd thing here is the creation and use of a cancel callback. I've not done much Go programming, so I don't know whether this is just a performance improvement to more quickly collect dropped iterator state, or it's a requirement because Go does not garbage collect goroutines waiting on channels for which the waiting goroutine has the only reference. In Lua you wouldn't need such a thing because coroutines/threads are GC'd like any other object--once all references are gone they're GC'd even if the last operation was a yield and not a return from the entry function.

[vaastav]

Garbage collector in Go is optional. You can switch off garbage collection by setting the environment variable GOGC=off.

More info about GOGC: https://dave.cheney.net/tag/gogc

[t8sr]

Only very theoretically - in Go, you don't control whether memory goes on your stack or the heap, and heap escape analysis is notoriously unpredictable. There is no explicit free. You would have to write Go in a completely crazy way to be able to turn off the GC and have the program not grow unbounded.

You might think "I'll just use static buffers everywhere", but allocations can occur in unexpected places. The compiler does some very basic lifetime analysis to eliminate some obvious cases (loops...), but it's really hard to avoid in general.

[gkfasdfasdf]

Ok so garbage collection is optional, how about garbage generation? Is there any way to manually clean up resources if GOCG=off, or will memory usage continue to grow unbounded as new objects are created?

[vaastav]

Grows unbounded. I wasn't recommending that one should set GOGC=off. Just making a remark that one could should they choose to do so.

EDIT: Sorry, I misunderstood part of your question. The memory grows unbounded unless you call runtime.GC() which triggers garbage collection. But this is a blocking call and essentially block your whole program.

[Cthulhu_]

I think in theory you can write code (or do some tricks) to avoid all heap allocation.

[t8sr]

"In theory" being the operative words there. Turn on heap escape analysis sometime, you'll be surprised how hard it is to avoid.

[dgb23]

You mean not growing the heap or literally no allocation?

[Tozen]

Arguably, one can't truly say the GC is optional, unless the language and its libraries were designed to work without it. In languages like Vlang, that's the case, as the GC was added later. If turning the GC off cripples the functionality and usefulness of the language, then there is little point in using the option or claiming it as optional.

Probably a better argument for Go (and other languages like Java) is how "tweakable" the GC is or at least describe it as the GC can be turned off, but it's not designed or useful to do so.

[kaba0]

Well, then so is in Java, with the Epsillon “GC”. But not collecting garbage is very different than manual memory management.