The use case motivating all the complexity is function iterators, where `range` can be used on functions of type `func() (T, bool)`. That has been discussed in the Go community for a long time, and the semantics would be intuitive/obvious to most Go programmers.

This post addresses the next thing: Assuming function iterators are added to the language, how do I write one of these iterators that I can use in a for loop?

It starts by noticing that it is often very easy to write push iterators, and builds up to a push-to-pull adapter. It also includes a general purpose mechanism for coroutines, which the adapter is built on.

If all of this goes in, I think it will be bad practice to use coroutines for things other than iteration, just like it's bad practice to use channels/goroutines in places where a mutex would do.

The go keyword nicely prevents the annoying function coloring problem, which causes quite a bit of pain.

Sometimes in high performance contexts I'd like to be able to do something like e.g. per CPU core data sharding, but this proposal doesn't scratch those kinds of itches.

But those were too much.

So we got threads, which are processes that share an address space, file table, and some other things. The scheduler can switch from one to the other more easily than between processes, and data can be shared between threads without needing serialization.

But those were too much.

So we got user space threads, which are logical threads of execution that are driven by a runtime entirely in user space. The runtime adds scheduling hooks into all I/O functions in the standard library, or even uses a system API like Unix signals to preempt logical threads. No system-level context switching is needed. User space threads can be tiny.

But those were too much.

So we got coroutines, which allow a programmer to define logical "threads" of execution that cooperatively interact with each other. There is no assumption about the presence of a scheduler. The programmer either writes their own event loop or invokes one from a library in a "real" logical thread.

I wonder what comes next. As far as [communicating sequential processes][1] are concerned, maybe cooperative coroutines are a low as you can go.

[1]: https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf

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?

    x := co func(){
        var z int
        for {
            z++
            yield z
        }
    }

    y := x()

    for y := range x {
        ...
    }

My $0.02, as someone that uses go at $work daily: I'd be happy to have either, but I'd prefer it baked into the language. Go's concurrency primitives have always been a strength, just lean into it.

Further, it doesn't seem to me to allow you to do anything you can't currently do with blocking channels and/or state.

- Many people consider coroutines and green threads to be more or less the same thing, when they both have their pros and cons.

- The fact that the omission of iterators is even acceptable in the Go community saddens me. They seem to deliberately refuse any feature that might make the language even slightly more complex, in the name of simplicity. But hey, at least they retracted their opinion on generics.

I'm again reminded that Go is not my language.

On the other side, given my experience with .NET and C++ co-routines, and Active Objects (in Symbian C++ and Active Oberon) not sure if this is really something to add to Go.

Even the .NET team has acknowledged at this year's BUILD, that if they could go back in time having the runtime handle them Go-style would probably been a better decision, given how many developers keep having issues understanding async/await.

At the same time, I am running the Erlang observer beside it to watch what happens to the CPU and memory consumption and how quickly it recovers/cleans up the garbage.

The biggest bottleneck here is the terminal's ability to keep up, but the observer seems to reflect what's happening accurately.

https://www.youtube.com/watch?v=yxyYKnashR0

The code I used: https://gist.github.com/pmarreck/4cc8f2f55a561ebce2012085a3a...

These features have been built into Erlang (and thus Elixir) since the 1980's. I'm sure many of you have heard of the Actor model and/or Erlang's "legendary" implementation of it, but I don't know how many have actually seen it in action with monitoring kit running.

I think it would be great for Go if it offered language-level support like this, but given the extremely resource-efficient implementation (both in spawning and runtime consumption) of threads on the BEAM VM, coupled with the ease of concurrency which comes directly from only permitting immutable values, I don't think it will ever be matched.

Just the question of whether one should use a goroutine or a coroutine adds complexity.

The natural solution to this is some sort of iterator, as in Python or other languages. (Contra frequent accusations to the contrary, the Go community is aware of other language's efforts.)

So this has opened the can of worms of trying to create an iteration standard for Go.

Go has something that has almost all the semantics we want right now. You can also "range" over a channel. This consumes one value at a time from the channel and provides it to the iteration, exactly as you'd expect, and the iteration terminates when the channel is closed. It just has one problem, which is that it involves a full goroutine and a synchronized channel send operation for each loop of the iteration. As I said in another comment, if what is being iterated on is something huge like a full web page fetch, this is actually fine, but no concurrency primitive can keep up with the efficiency of incrementing an integer, a single instruction which may literally take an amortized fraction of a cycle on a modern processor. With generics you can even relatively implement filter, map, etc. on this iterator... but adding a goroutine and synchronized commit for each such element of a pipeline is just crazy.

I believe the underlying question in this post is, can we use standard Go mechanisms to implement the coroutines without creating a new language construct, then use the compiler under the hood to convert it to an efficient execution? Basically, can this problem be solved with compiler optimizations rather than a new language construct? From this point of view, the payload of this article is really only that very last paragraph; the entire rest of the article is just orientation. If so, then Go can have coroutine efficiency with the standard language constructs that already exist. Perhaps some code that is using this pattern goroutine already might speed up too "for free".

The concerns people have about this complexifying Go, the entire point of this operation is to suck the entire problem into the compiler with 0 changes to the spec. Not complexifying Go with a formal iteration standard is the entire point of this operation. If one wishes to complain, the correct complaint is the exact opposite one, that Go is not "simply" "just" implementing iterators as a first class construct just like all the other languages.

Also, in the interests of not posting a full new post, note that in general I shy away from the term "coroutine" because a coroutine is what this article describes, exactly, and nothing less. To those posting "isn't a goroutine already a coroutine?", the answer is, no, and in fact almost nothing called a coroutine by programmers nowadays actually is. The term got simplified down to where it just means thread or generator as Python uses the term, depending on the programming community you're looking at, but in that context we don't need to use the term "coroutine" that way, because we already have the word "thread" or "generator". This is what "real" coroutines are, and while I won't grammatically proscribe to you what you can and can not say, I will reiterate that I personally tend to avoid the term because the conflation between the sloppy programmer use and the more precise academic/compiler use is just confusing in almost all cases.

Lua is an absolute work of art. Everything about the tiny language, how it works, and even all the little peculiarities, just makes sense.

I haven't thought much about iterators link to coroutines.

As a hobby, I am working to write about a dream programming language. I happen to be really interested in parallelism, asynchronous, coroutines, multithreading and concurrency.

I want:

* seamlessly switch between remote-thread coroutine, local thread coroutine.

* concurrency and parallelism and async to be easy to think about, reason about, read and program

* programs should be easy to parallelise and be async and concurrent

Go iterators seem to be local to a thread, but what if you want to distribute work across threads?

I've been thinking of scheduling recently.

Imagine you're a search engine company and you want to index links between URLs. How would you solve this with coroutines?

  task download-url
   for url in urls:
    download(url)

  task extract-links
   parsed = parse(document)
   return parsed

  task fetch-links
   for link in document.query("a")
    return link

  task save-data
   db.save(url, link)

* `db.save()`, `download()` are IO intensive whereas `document.query("a")` and `parse` is CPU intensive.

* I want to handle plurality or multiple items trivially such as multiple URLs and multiple links.

* I want to keep IO and CPU in flight at all times.

I think I want this schedule:

https://user-images.githubusercontent.com/1983701/254083968-...

I have a toy 1:M:L 1 scheduler thread:M kernel threads:N lightweight threads lightweight scheduler in C, Rust and Java

https://github.com/samsquire/preemptible-thread

This lets me switch between tasks and preempt them from user space without assistance at descheduling time.

I have a simplistic async/await state machine thread pool in Java. My scheduling algorithm is very simple.

I want things like backpressure, circuit breakers, rate limiting, load shedding, rate adjustment, queuing.

i think this would be favorable for (among other things) clu-like iterators and imgui libraries, where you often want to do something like

    submenu("&Edit") {
        command("&Cut") { clip_cut(getSelection()); }
        ...
    }

the conventional way to do this is to package up the block into a closure, then use a full-fledged function invocation to invoke it, using a calling convention that supports closures. but i suspect a more relaxed and efficient approach is to use an asymmetric coroutine calling convention, in which the callee yields back control to its caller at the entry point to the block, and the block then resumes the callee when it finishes. so instead of merely dividing registers into callee-saved and call-clobbered, as subroutine calling conventions do, we would divide them into callee-saved upon return but upon yield containing callee values the block must have restored upon resumption; caller coroutine context registers, which are callee-saved upon return and also on yield; and call-clobbered. you also need in many cases a way for the block to safely force an early exit from the callee

this allows the caller's local variables to be in registers its blocks can use without further ado, or at least indexed off of such a register, while allowing the yield and resume operations to be, in many cases, just a single machine instruction. and it does not require heap allocation

as an example of taking this to the point of absurdity, here's an untested subroutine for iterating over a nul-terminated string passed in r0 with a block passed in r1, using a hypothetical coroutine convention which passes at least r4 through from its caller to its blocks

    itersz: push {r6, r7, r8, lr}
            mov  r7, r0
            mov  r6, r1
    1:      ldrb r0, [r7], #1
            cbz  r0, 1f
            blx  r1
            b    1b
    1:      pop  {r6, r7, r8, pc}

    hashsz: push {r4, r5, r9, lr}
            movs r4, #53
            adr  r1, 1f
            blx  itersz
            mov  r0, r4
            pop  {r4, r5, r9, pc}
    1:      eor  r4, r0, r4, ror #27
            bx   lr

it's less general than the mechanism russ proposes here (it doesn't solve the celebrated samefringe problem), but it's also an order of magnitude more efficient, because the yield and resume operations are less work than a subroutine call, though still more work than, say, decrementing a register and jumping if nonzero

Sieving primes by turning functions into coroutines, parsing text by yielding characters, all with unnatural functions and state management... that;s an improvement over what?

Java and C++ are largely inferior for my typical purposes, but at the end of the day they work fine and are stable in terms of direction, and don't tend to repeatedly bloat the language over pedantry. If you want top-notch performance, there's already C, C++, and Rust.

I am not a fan of the function coloring shit in Python and Javascript.

I don't want the kitchen sink!

Coroutines will fill a different nice more akin to Python's generators. There are a whole bunch of places where this could dramatically cut down on memory usage and code complexity where you have a composable pipeline of components you need to glue together. The design appears to me to be entirely synchronous.

The good thing is, nothing in the post even proposes anything that might fall in the function coloring problem.

FYI when you write a goroutine and have to use Context, that's literally just function coloring

Usually my goroutines related code feels like a mess because of them, and I don't know how to make them "more clean" (whatever that means). Any hints proven to be maintainable patterns would be highly appreciated.

Hasn't Microsoft done some research on such a language years ago already? There is also ParaSail made by someone from the Ada community. What happened to these projects? Nobody uses them?

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.

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

Well, maybe a library solution could possibly have a guard page at the end of the stack. When that one is reached, then you could try to grow the stack in an error handler. (but that would probably not work, if you have taken a pointer to some stack variable)

This means that for a function to yield, it needs to have the so called `yield` param and you can only yield inside a yield function functions with the same yield signature or does not contain a signature at all.

So the example would be rewritten into something like:

  x := func(:z int) {
    for {
      z++
      :- z
    }
  }

  for y := range x() {
    ...
  }

Functions that only yield a value `X` would just have the `: X` or `: name X`. To accept a value of type `Y` in the resume the signature would change to `:[Y] X` or `:[Y] name X`.

Accepting is weak, so if something expects a yielding function that resumes with Y and yield X, yielding functions that only yield X without a resume should also be accepted.

Consider the following code example:

  func filter[T comparable](it func(:T), f func(T) bool, :T) {
    for v := range it {
      if f(v) { :- v }
    }
  }

  func map[T](arr []T, :T) {
    for _, v := range arr {
      :- v
    }
  }

  for v := range filter(map({1, 2, 3}), func(x) { return x < 3 }) {
    print(v)
  }

A basic counter could be written like this:

  func counter(:[bool]c int) {
    for {
      if ! :- c { break }
      c += 1
    }
  }

  func countTwice(:[bool]c int) {
    count()
    count()
  }

  for c := range count() {
    if c > 10 { -: false }
    -: true
    print(c)
  }

I use them now somewhat, but only because they offer slightly better sugar at the call site. at the definition site, they are just as ugly as you expect, granted the Go syntax is about the best I have seen from other languages. so in the end I think we really lost some simplicity in order to silence the whining about no generics. not a good tradeoff.

No, we really didn't.

Generics were acceptable to the community only because they are fully backwards compatible with existing code, and can be safely ignored if you don't need them.

Which, not at all surprising, is what most golang code still does. Because as it turns out, outside of "collections" of one sort or another, practical use cases for generics are not that easy to find. Most code written never gets to see more than one type to begin with, and more than 2 is already a stretch.

If anything, the addition of generics showcased to the larger community, how little many of the vaunted features!!!!! that people keep demanding and labeling as "essential" are actually needed for a widely accepted and excellent language.

I don't remember where I came across this, but many years ago I saw python-style generators termed "semi-coroutines" which I'm a fan of. Python (frustratingly) doesn't implement them this way, but the beauty of generators is that by limiting the scope where execution can be suspended to the highest-level stack frame, you can statically determine how much memory is needed for the (semi-)coroutine, so it doesn't require a single allocation.

Zig takes that a step farther by considering recursive functions second-class, which lets the compiler keep track of the maximum stack depth of any function, and thereby allow you to allocate a stack frame for any non-recursive function inside of another stack frame, enabling zero-allocation full coroutines, as long as the function isn't recursive.

That would... probably be overkill for Go, since marginal allocations are very cheap, and you're already paying the runtime cost for dynamic stack size, so the initial allocation can be tiny.

I would love to see full proper coroutine support make it to Go, freeing users of the overhead of the multithreaded scheduler on the occasions where coroutine patterns work best. I remember back in 2012 or so, looking at examples of Go code that showed off goroutine's utility as control flow primitives even when parallelism wasn't desired and being disappointed that those patterns would likely be rare on account of runtime overhead, and sure enough I hardly ever see them.

            @ hashsz s = {
            @   h := 53u
            @   itersz s, b => {
            @     h = (h >> 27 | h << 5) ^ b
            @   }
            @   return h
            @ }

            .syntax unified
            .thumb
    itersz: push {r6, r7, r8, lr}   @ r6 and r7 are preserved by blocks
            mov  r7, r0             @ so put the string pointer in r7
            mov  r6, r1             @ and the block code pointer in r6
    1:      ldrb r0, [r7], #1       @ loop over string bytes, post-indexing
            cbz  r0, 1f             @ bail out on NUL, but otherwise
            blx  r1                 @ invoke block argument with byte, then
            b    1b                 @ repeat loop
    1:      pop  {r6, r7, r8, pc}   @ restore registers and return

    hashsz: push {r4, lr}           @ r4 is callee-preserved and passed to blocks
            movs r4, #53            @ initial value of hash
            adr  r1, 1f+1  @ load Thumbified pointer for block using gas local label
            bl   itersz             @ invoke iterator subroutine
            mov  r0, r4             @ load completed hash into return value
            pop  {r4, pc}           @ restore and return
    1:      eor  r4, r0, r4, ror #27  @ block argument rotates & xors the byte in r0
            bx   lr                 @ then resumes the iterator