It is, and it’s not directly tunable … the opinion is ‘we’re IO-bound, not compute-bound’.
I spent a chunk of time recently (10s of hours) doing dumb C# vs Go benchmarks - files and networking, and nothing worth taking seriously - just, usually the part about being IO-bound was true. C# is really impressive and was just a little slower with the best async solutions I could come up with. The machinery for async has overhead, so do Go routines and channels … the first-pass, not very performant code was just a little faster and IMHO clearer with Go (but I’m much better with Go /shrug).
nah he just compares two different things.
basically his golang hello world probably had basically nothing while his dotnet version used the "Microsoft.NET.Sdk.Web" which basically pulls the shared framework which will load a ton of stuff.
BUT even after that the memory usage might be bigger. however does it really matter? I mean dotnet is not a big memory hog. it's pretty lightweight for what it is. compare it to java and the golang number would be insane.
I tried to do the most minimal, idiomatic design for both. I didn't save the C# code (I think it probably was just asp.net core and newtonsoft.json), but here is the go version [1].
It basically just loads a JSON file into memory then allows you to query the data with 2 API endpoints.
well asp.net core is not really minimal or idomatic.
it pulls a whole framework your code doesn't do a lot of things that asp.net core would do. sadly since nancyfx died there arent that many c# http framework that are as lightweight as the golang once. asp.net core is more like java spring btw.
nowdays most c# http frameworks do call
`<FrameworkReference Include="Microsoft.AspNetCore.App" />` which is really really big compared to just Microsoft.NETCore.App most often the defaut aspnetcore also configures a "secure" application (working cors, etc.)
