> It is more accurate to specify that Go favors the sweet spot of "smaller" amount of work ... focuses on maintaining consistent latency ...
It seems like you wrote the same thing that I wrote, but you used different words for it. What you described is basically I/O-bound workloads with a particular emphasis on latency—in other words, the category of networked services, which is precisely what Go was created for and why we use it.
> In a way, .NET's GC is evolving in a similar direction but attempting to maintain the throughput or ensure the loss is within single digit %.
Let me know when it finally evolves! I would like to try it out for some of our smaller services then. When we started building our core services in Go many years ago, .NET Core wasn't as good in terms of network throughput, latency, and handling multiple I/O-bound tasks simultaneously. I was actually evaluating it back then too.
PS. From one of our production nodes from the last 24h:
Can't say I'm a huge fan of it but it gets the job done. In general, ASP.NET Core and Kestrel are great, particularly when you look at just how much more CPU and RAM (and boilerplate) Spring and Node.js require to deliver the same amount of functionality (validation, rate limiting, caching, middlewares, etc.), but because the pipeline is quite a bit UTF-16 centric and feature-focused, it mostly manages to provide competitive performance through sheer performance of the foundation it is built on. .NET could use a custom implementation, much like what Garnet does under the hood, to fully take advantage of compiler and memory management improvements and reclaim top positions in techempower :)
You may notice that GC is more size-efficient on Linux and Windows than on macOS. There is an internal feature regarding its heap management (regions) that is not enabled for the latter due to some tooling integration issues. It will eventually get fixed but due to minor impact (people aren't using macs for hosting) of it, it hasn't been a priority.
Another project which I think is a good showcase even if unrelated to the domain you work with: https://github.com/codr7/sharpl - can be compiled with dotnet publish -o .
The sort of thing people often build in Go. Because it is completely custom it is really good at demonstrating just how much native AOT compilation tooling has improved and how low base application footprint gets wrt GC and runtime. Might take a bit to compile for the first time - it needs to pull ILC (IL AOT Compiler) from nuget.org. Not going to be as fast as Go build times (.NET 9 improves it) but you often don't need that - for quick iteration during dev there is dotnet watch for hot-reload instead.
It seems like you wrote the same thing that I wrote, but you used different words for it. What you described is basically I/O-bound workloads with a particular emphasis on latency—in other words, the category of networked services, which is precisely what Go was created for and why we use it.
> In a way, .NET's GC is evolving in a similar direction but attempting to maintain the throughput or ensure the loss is within single digit %.
Let me know when it finally evolves! I would like to try it out for some of our smaller services then. When we started building our core services in Go many years ago, .NET Core wasn't as good in terms of network throughput, latency, and handling multiple I/O-bound tasks simultaneously. I was actually evaluating it back then too.
PS. From one of our production nodes from the last 24h:
GC Pause time:
Min: 85.1 µs
Max: 343 µs
Avg: 150 µs
https://imgur.com/0HjUyM7