So C++ is bad because certain functions should be avoided and has no garbage collector. (With C++11 STL normally there's no need for manual memory management or naked pointers.)
C# is good, just you should avoid the garbage collector and 90% of the standard library. Roll your own web server, raw sql commands, have manual memory management, use undocumented calls, emit byte code and there you have: almost 40% of the C++ performance.
I'm the only one who thinks this does not make any sense?
No, I'm not implying any of that. I'm just saying that an important step to getting good performance is profiling to determine the cause of poor performance, then deciding whether it makes sense to try to improve performance in the found areas, then executing your decision.
Imagine the alternative if I didn't profile: I'd just declare that C++/whatever is way faster than ASP.NET, and I'd switch to C++ and open myself to a whole world of debugging memory corruption issues whatnot. Instead, because I profiled, I found the areas that could be improved, I wrote the HttpListener code and I can stay on the .NET platform for all of its other benefits. By following this process I have more options than just "C# blows, I gotta throw it out the window for C++".
In reality, I have probably written more useful, shipped, production C/C++ than C#, so I'm also a C++ advocate, but hey, when it makes sense, and for the right reasons, you know?
I don't understand how you got there from the parent post. The github links look like idiomatic C# to me, aside from avoiding IIS. IIS has nothing to do with C# vs C++ vs anything else.
C# is good, just you should avoid the garbage collector and 90% of the standard library. Roll your own web server, raw sql commands, have manual memory management, use undocumented calls, emit byte code and there you have: almost 40% of the C++ performance.
I'm the only one who thinks this does not make any sense?