[pygy_]

Go is strongly opinionated and very normative (which is a good thing for its main target audience). It's not surprising it attracts people who would look down to you for departing from the norm, even if your choices are technically justified.

[ithkuil]

Do you have any examples or data to support that there is any benefit by employing a explicit asynchronous IO pattern rather than relying on the Go IO libraries perform the select() (epoll or whatever...) syscall and then rely on the goroutine scheduler to switch control to who is registered to do something when the data is ready?

Is the default minimal stack segment size too big? Or the scheduler too heavyweight?

[tptacek]

In the case of a proxy, the select(2) call implements the simple predicate "should I read from the client or the server". It turns a pair of coroutines into a single normal routine. The single routine is clearer, perhaps marginally less performant for a single connection, but probably marginally more performant across a large number of connections.

The "asynchronous pattern" thing is a religious canard. Golang devotees are (rightfully) happy to abandon event-structured programs in favor of programs that look like socket tutorial code but perform like event servers. But we're not talking about asynchronous control; we're talking about a synchronous loop. I've noticed this when talking to Golang people: they hear "select" or "poll" and automatically a switch goes off in their head that lights the "BAD!" lamp. I'm not sure that's valid.

Another example, which I gave upthread, was a high-speed port scanner; when I left it to the Golang scheduler to handle the sockets without Golang's timeout idiom, I quickly starved the program of sockets, because of the interaction between timeouts and the scheduler. I pulled select(2) into the program (for that one use only! Just to avoid using Golang timeouts for a simple connect(2) timeout) and the program not only ran quickly but properly handled the socket descriptors.

This isn't a critique of Golang, which I like working with. Rather, I'm criticizing a specific Golang idiom.

[ithkuil]

I'm sorry, I'm not sure I follow you. Is the problem with your high speed port scanner lie in the implementation of DialTimeout or you for some reason you had to use syscall.Connect in a new goroutine and implemented the timeouts with select{} ?