| I'm somewhat sad they didn't include a few things: - a box/whisker plot in the latency comparison graph — esp. if we're to talk about Go's GC... - some discussion/arguments why the particular C implementation was chosen ("tapip") — I'm not an expert in this area so I don't have the slightest idea how notable it is; - how did they detect/measure the claimed memory leaks in C? also, some statistics about the claimed crashes? - isn't clear to me if they used some "well known" load testing tools, or some homemade framework? (e.g. "siege" is a tool I read about more than once?) - more details on how exactly the "correctness was determined by testing against Linux kernel [implementation]". That said, my initial loose conclusions from this seem to be: - it appears it may be easier to write a correct implementation in Go (the implementation seems to be written just ad hoc by the article authors?) than in C; - it appears it may be easier in Go than in C to write an implementation scaling well w.r.t. average latency & throughput, assuming the need is for a multi-threaded & user-space implementation. |