> Coroutines are lower-level [than M:N threading]

Not sure I understand what you're trying to say here, this sounds exactly backwards to my reading. A green threading library can be written in assembly language with no reference to anything but the hardware ISA specification and the ABI that defines the relevant calling convention. It's as "low level" as a software construct can be. The only lower level implementation I can think of are hardware-assisted context switching features like you see on some embedded architectures.

Coroutines, on the other hand, are artifacts of the language runtime and depend in sensitive ways on that whole stack. Much higher level.

> Not sure I understand what you're trying to say here

The exact sense of the phrase you excerpted is explained in the next clause of the same sentence of the comment.

OK, then that's backwards, sorry. The fact that A is hard to implement in terms of B doesn't mean that A is a "lower level" (or even "higher level") construct in the sense people usually use those terms. It just means that the two metaphors are incompatible.

Honestly I was asking the question because I thought you had some deeper point in mind I couldn't see. But you just had it backwards.

That's kind of the problem when the author uses meaningless words like "WEB SCALE", we don't really know what it means exactly.

If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.

Most languages give you one of two easy options. The first is to use green threads, which makes 100,000 new threads cheap, but now a single slow function call anywhere can block other threads. The second is to use OS threads, which keeps a slow function call in one thread from interrupting your responsiveness, but now makes 100,000 new threads expensive.

What M:N threading does, at least in theory, is allows you to create 100,000 threads cheaply AND keep a slow function call in one thread from blocking others. In a language with those features you can build it out of continuations (NOT coroutines) and real threads. But that requires building your own scheduler that can move a user thread to a different process at need. Which is non-trivial, and is unlikely to cooperate well with any third party libraries.

That said, whether M:N threading is a real optimization depends on a ton of things. A big one is the underlying performance of the scheduler and the language. Which is improving for Perl 6..but has a long way to go.

Whether optimizing at this level matters is another good question. Most companies shouldn't care. Those that should, should be cautious about deploying Perl 6 into a mature infrastructure.

So that's why people can think that M:N is important, and why you might legitimately disagree.

Very useful explanation. Thank you.

> That's kind of the problem when the author uses meaningless words like "WEB SCALE", we don't really know what it means exactly.

When the author (as is the case here with M:N threading) identifies the specific feature of interest, we do know exactly what it means, independently of whether they also reference something less precise.

> If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.

If you want to posit an argument challenging the idea that M:N threading is an advantage, that's a different thing that disagreeing with the authors contention that choices are fairly limited if you want a language with language-level integration of M:N threading.

Author demonstrates exactly what is meant with code exam in the article