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 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.