It is worth noting that the key to this is that the language is designed so that even the synchronous appearing APIs for things like file IO actually use the no

It is worth noting that the key to this is that the language is designed so that even the synchronous appearing APIs for things like file IO actually use the non-blocking system calls under the hood, so that the OS thread does not get blocked, and other goroutines can be scheduled. When calling into C code, there is additional overhead of potentially creating a new OS thread to continue running goroutines on, since go has absolutely no idea if the C code will block, but since the average C library does use blocking IO, it needs to either assume the worse, or alternative have an OS thread dedicated to monitoring for kernel level blocking, and spawning new goroutinine runing threads. (I believe the assume C calls may block approach is used.) It has heuristics to avoid creating a new OS thread every time, but in any case, if you have many goroutines calling a blocking C function call, it means you have many blocked OS threads too.