>Nothing there tells you how async or not the server implementation is, and that `os.write()` call might be using a thread pool underneath.
It depends on the contract of the method. If it promises to throw an exception if the call failed, then the current thread of execution can't proceed before the call returns, or it would break the semantics. So even if it uses a thread pool, the current thread will have to block, waiting for some acknowledgement by os.write(), wasting an entire OS thread. As far as I know, Go won't block, the scheduler will just switch to a different goroutine in the meantime. Java's new virtual threads will allow to have mechanism similar to Go's.
It depends on the contract of the method. If it promises to throw an exception if the call failed, then the current thread of execution can't proceed before the call returns, or it would break the semantics. So even if it uses a thread pool, the current thread will have to block, waiting for some acknowledgement by os.write(), wasting an entire OS thread. As far as I know, Go won't block, the scheduler will just switch to a different goroutine in the meantime. Java's new virtual threads will allow to have mechanism similar to Go's.