> What is the "significant performance tax" in Go?
I explain in this sibling comment: https://news.ycombinator.com/item?id=12271194
> Do you have any numbers about this implementation?
See the blog post.
I did edit my first question after seeing the numbers.
Arguing about whether a 30% difference is "significant" isn't really interesting.
You're talking about using a language where you have to manually manage the memory, is significantly harder to use than Go, have less built-in concurrent patterns, inferior standard library, so yes 30% seems a very small benefit.
I didn't had look into the benchmark but my guess is that it's waiting on the I/O so any language with good concurrent model will have the same numbers.
The benchmark would have been more interesting if it was more CPU intensive, that would have definitely favored Rust.
it's not about Rust Vs Go, it's just that 30% seems very low when you know how fast Rust is vs Go in some scenarios.
> You're talking about using a language where you have to manually manage the memory, is significantly harder to use than Go, have less built-in concurrent patterns, inferior standard library so yes 30% seems a very small as a benefit.
Naturally I disagree with all of those items, but I'm also equally uninterested in starting a Rust vs. Go war.
When I look at the benchmark of your minihttp vs Go fasthttp, Rust is supposed to be 3x time faster without any GC and yet minihttp pulls 2M req/sec VS 1.5 for Go which is a small margin when you know how Go works and is GC.