Usually where I see C# slow down is not because of the language, but because of over engineered "enterprisey" solutions that Java has a bad rep for e.g. having things like a FactoryProviderFactory type idioms.

A lot of the projects I work on, for instance, heavily utilize dependency injection for no gain. There's only one implementation, theres no test mocks. Its just overengineered and obsfuscated for no reason.

Coming from a predominantly C++ background, we eschew virtual wherever possible, favoring compile time polymorphism to runtime whenever possible, because we're cognizant of the overhead of the indirect dispact and likely loss of optimized opportunities to inline trivial calls.

For sure, one can write C# or Java that can keep up, or even outperform C++ in some circumstances, but youre not going to do it with "enterprise" patterns hiding behind interfaces and factories and dependency injection.

That isn't how Turbo Vision, OWL, VCL, MFC, Motif++, PowerPlant, C Set++, ATL, Qt, Unreal, COM/UWP, wxWidgets, JUCE look like.

There are the CppCon talks, the Modern C++ advocacy, and then there is the code that everyone at most corporations actually write.

Virtual dispatch is particularly well suited for constructing dynamic GUIs at runtime. Doesn't mean that "everyone" is writing code like that.

COM/UWP is not only for GUIs, it is the full area of modern Windows APIs.

Then there are ORM like the ill fated POET.

Yeah just like not everyone is writing code that "eschew virtual wherever possible, favoring compile time polymorphism to runtime whenever possible", specially on large corporations with mixed language teams.

Beyond C++ conference talks, I am yet to see stuff like SFINAE and tag dispatching in the C++ code I occasionally deal with. Grated those are libraries that get called from Java/.NET projects.

I have written a fair amount of C++ template metaprogramming and policy based libraries. One library I wrote, in particular, was a templated generic matching engine primarily used in the self-clearing of trades. Through template policies, it could be configured to do one-to-one, on-to-many, many-to-many matching based upon template args, for example. I also did a bit of SFINAE in writing a home-grown ORM lib. I haven't really written any libs using tag dispatching, but I've certainly used my fair share (looking at you, Boost MultiIndex).

You don't usually see these sorts of types wrapped for Java or .Net, and if they are, you usually have some sort of proxy in between to hide the templates.

Saying "The hype and claims we see in blogs that are not backed up by anything?" followed by "Both C# and Java are faster than golang" without substantiating the claim is the pot calling the kettle black.

If you do have links to share, however, please do.

I mean this benchmark itself proves it's as fast or faster, the latency is well lower than C# and Java and probably the memory usage too.

Now for some "popular" benchmarks:

https://www.techempower.com/benchmarks/

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

You see that Go is sometimes faster sometimes slower but the memory usage and latency is way bellow both of those languages.

I know of the techempower benchmarks. You'll notice that the go results that end up scoring highly are using "atreugo", a customized low allocation implementation. That's how it gets its speed. Java and C# on the other hand are using fully fledged framework implementations (e.g. Vertx or ASP.NET).

You end up with a highly customized implementation not suited for wide use to get the higher performance benefits (and it still doesn't beat java on benchmarks like single/multiple queries and JSON serialization).

All these benchmarks should be taken with a large grain of salt. The golang compiler doesn't even pass function variables in registers (they're all stack allocated as far as I know), let alone do any of the advanced inlining and optimizations the JVM does.

This is not accurate, if you look at the dependencies of the project: https://github.com/savsgio/atreugo/blob/master/go.mod it uses well known libs like github.com/valyala/fasthttp.

Which is still a specialized library, and not widely used like golangs standard library. And comes with its own set of disadvantages

Vertx is not part of the standard library either, saying that Fast HTTP is a spezialized lib is very missleading since it's widely used.

This talk is by the author of fasthttp[1]. Note the caveats that come with it. Also, it is nowhere near as widely used nor established as Vertx.

[1] https://docs.google.com/presentation/d/e/2PACX-1vTxoBN41dYFB...

> Both C# and Java are faster than golang.

In this case Golang outperforms (in terms of throughput) Java on batch sizes > 4 and does so by nearly 2x at batch size of 256.