Yes exactly. The author’s design decisions only make sense if this is supposed to be a toy language. On using pthreads rather than fibers:

> I decided not to use one. I wanted something dead simple — an approach I could explain in a paragraph, using tools every C programmer already knows. The trade-off is that you lose some performance with fine-grained blocking, but in many real-world situations, pthreads work fine if you use a worker pool.

Sure. You can take a large production Go app and measure how many user space threads are launched; it’s decidedly a lot more than the typical number of threads if you were using pthreads.

And the author didn’t really justify why select isn’t implemented other than implementation difficulty.

I've been using Go regularly since 2012. Worker pools are completely valid and idiomatic in Go. Not sure how you read that quote and concluded "toy".