Go vs .NET Core in terms of HTTP performance

They are using the Iris framework, the one the Go community doesn't recommend to use due to numerous instances where the package author would rewrite the history of the project. See [1][2].

[1] https://github.com/avelino/awesome-go/pull/1137

[2] http://www.florinpatan.ro/2016/10/why-you-should-not-use-iri...

Besides, you don't really need a framework to develop programs for the Web in Go. It would be interesting to see this comparison with only `net/http` from the stdlib.

EDIT: Apparently this post is also written by the author of Iris. I would be doubly careful.

I have mixed feelings about these types of comparisons.

On one hand, they provide some directional information. I wouldn't be surprised if a Go framework is generally faster than .NET.

On the other hand, they're usually set up in some suspect way: not quite apples to apples, the author knows one framework better than the other, or, most commonly, neglect other more important concerns. If I were considering Go vs .NET, I don't think serving 5 million requests in a burst would be very close to the top of my wishlist. Tooling, documentation, ecosystem, ease of hiring, open source projects, etc etc etc all seem far more important, but you don't see these in comparison articles all that often.

Lip service benchmarks like this don't help anyone. They just add fuel to the ignorance fire. Why was the Go version faster? Without profiling the code being benchmarked it doesn't really mean anything, since any number of unrelated factors could have affected it.

For example, did you know that until recently Go's HTTP/2 client didn't do flow control? Sending cross continent requests could easily result in slowness. Did the Go program in this test use the updated code? If not, it may have been much faster. See how not understanding why it's slower leads to not understanding?

.NET may actually have been faster, but we won't ever know because the author didn't really understand what was going on.

One of the commenters on the original article (https://medium.com/@tarthedark/did-a-custom-bench-between-ht...) changed a few lines of the C# to use some different ASP.NET facilities which more than doubled the reqs/sec and dropped the std dev of latency by 2/3. That provides some evidence that it wasn't really an apples-to-apples comparison.

Beyond that, a synthetic benchmark such as this one in which no real work is being done to service an HTTP request is unlikely to translate into real-world performance since the "real work" factors such as disk IO or database access are likely to dominate the HTTP request/response code paths. IMO, one of the places where C# shines is its thorough support for asynchronous I/O (of all kinds -- not just network) so that these kinds of services that do "real work" scale up efficiently on multi-core systems. I am also impressed with how fast Golang is, but you really have to compare the systems with real workloads over time periods sufficient to fully stress GC on their production platforms to see which will be faster.

One strange thing I notice right off the bat is that one metric the author is using to compare is Lines of Code (where smaller is better):

>.NET Core MVC Application, written using 86 lines of code...

>Iris MVC Application, written using 27 lines of code...

But the files are formatted differently...

In C#:

    public void Delete(int id)
    {
    }

In Go:

    func (vc *ValuesController) Delete() {}

The author of this benchmark is banned from almost all Go benchmarking repos on GitHub, because he consistently tried to fake benchmarks, violated licenses, stole code, and dozens of more stories.

@ainar-g, @velodrome and @OoooooooO said it already well enough that this benchmark is not in any way realistic, or useful, and that the author is untrustworthy.

I’ve flagged the article.

I think that the ultimate takeaway from this benchmark is that both languages/frameworks are fast enough out of the box.

Once you mix I/O into the equation, that is going to become your bottleneck. Also you may care about language features that may or may not make you program faster.

Golang abstracts async I/O out of the box and is natively compiled, but lacks generics and exceptions. .NET core must be explicitly programmed to make use of async I/O and is JIT compiled, but provides richer language features. Pick your poison.

If you're new here, ignore hateful comments about @kataras and his very well written article, there is a certain community part (small around 5-10 people) in Go world which is jealous about everything @kataras had accomplish so far and they are putting the same comments with different accounts everywhere, just to know.

@kataras if you ever see my comment: please do never stop Iris, hear us the 99% of the Go Community and ignore people like @dlsniper and his fake accounts, the majority of the Go community and with a proof of your article's 234 medium likes at just 2 days are awesome results of your hard work. Who cares about a jealous minority?

Edit: There is a new article from the same author about Kestrel performance: https://medium.com/@kataras/iris-go-vs-net-core-kestrel-in-t...

The author of this article is also the author of the Iris framework.

A framework that includes a lot of stolen source code from other Go frameworks, faked benchmarks, flattend git histories and blatant lies when caught stealing and faking and lying

The same link was also already here with direct links to his lies and the opinion of the Go community about his behaviour (in short, everybody hates him for his bullshit).

https://news.ycombinator.com/item?id=15058500