3 ms·
Go is missing a few things for this. There is no good predictable event-driven polling library for networking with proper error handling and no GC pressure (no
by zzzcpan 11y ago
Go is missing a few things for this. There is no good predictable event-driven polling library for networking with proper error handling and no GC pressure (no heap allocations), etc. And it has to implement its own syscall wrappers, because Go's syscall wrappers on non-blocking FDs call into the scheduler and even produce garbage on some errors. TLS library needs to be predictable too, produce no garbage and play well with polling.
Doing it in idiomatic way and dealing with all that goroutine per request model, concurrent memory access and unpredictable GC pauses is simply not worth it. It's going to be safer, but not of a decent quality. Better to live with what we have.
For Rust, I imagine, it's going to take even more work.
- tptacek 11y agoThere's no good predictable event-driven polling library for networking because the whole runtime is a good predictable event-driven polling library for networking. You're not supposed to "event" Go I/O. Virtually every Go program that anyone has deployed at scale has scaled I/O with goroutines (though not necessarily with "concurrent memory access"). With the exception of NTP, I can't see a single example of a service in the list I provided that is sensitive to "GC pauses" on the scale you'd end up with in an idiomatic Go program.
- zzzcpan 11y agoYou are not doing event-driven programming just to scale I/O, you are doing it to avoid mutexes and concurrent memory access, to have easy cancellation, easy management of connections and other resources, etc.
- tptacek 11y agoIdiomatic Go code also doesn't use mutexes and concurrent memory access, unless you're trying to argue that channels are implicitly mutexes. Also: you now seem to be subtly backing off your original point. Can we stipulate that the performance of most network programs would not be meaningfully improved by switching from M:N I/O scheduled threads to async I/O?
- zzzcpan 11y agoMy original point was about _predictability_ of performance and accidental complexity, that M:N threads with synchronous APIs introduce. But either way, they use way more memory, than necessary and also have to implicitly and explicitly synchronize every little thing, so performance on any meaningful load is going to be very meaningfully worse, than that of event loops. Still, I want to reiterate, that event loops in modern languages are more about managing complexity, than performance.
- mikecb 11y agoSome think it's very appropriate for high performance networking: https://github.com/google/stenographer https://github.com/google/stenographer Granted, that uses pfring pretty substantially, but still...