The advantage of coroutines isn't inside the lexer itself, but in synchronizing the lexer (or let's say parser, which can handle nested structure) with whatever

The advantage of coroutines isn't inside the lexer itself, but in synchronizing the lexer (or let's say parser, which can handle nested structure) with whatever consumes its output. Look at SAX-style XML parsers like expat or libxml2: they recursively parse the XML events (tags etc.) to the client through user-supplied callbacks, an annoying control inversion. An alternative could be to reify the parse stack inside some data structure but recursion is way more natural. Coroutines solve the problem: you call the parser, and it returns tags as it encounters them, from arbitrarily deep inside its own parse tree. I think goroutines were intended more for i/o concurrency than as a control flow mechanism, so the performance issues aren't surprising. I wonder how the benchmark would look with C++20 coroutines. I was going to say protothreads but I think those are not allowed to be recursive. As for listening to your professors, well, Knuth vol 1 all the way back in 1968 advocated coroutines as a more powerful generalization of subroutines ;). The ease of implementing very lightweight and fast multitaskers is one of the traditional attractions of Forth, if that matters.