You're not really making a lot of argumentation to back up your claims. Anyone can Search engine benchmarking and get the results they want. Just look here:
For our specific use case C#'s TPL was ok, but it comes with a massive overhead compared to Goroutines. We can have tens of thousands concurrent threads running at the same time at very little CPU usage (which is primarily what we pay for). It’s not that you can’t use async/await tasks to do the same, but they use a lot more CPU and as such is less cost effective for us.
As far as blocking and having meaningful (again meaningful is the keyword) cancellation I encourage you to look to Microsoft and understand the limitations outlined by them in the learning articles starting here:
> You're not really making a lot of argumentation to back up your claims. Anyone can Search engine benchmarking and get the results they want.
This is only possible if you completely ignored the text in my comment and never used C# and Go concurrency primitives side-by-side to evaluate them on their merits. The race conditions risks in Go are very real and so are issues w.r.t closing channels, passing nils, etc. The __much higher___ cost of spawning channels and gorotines is equally as real and you can measure it yourself. Both are intended to be spawned for longer than shortlived scenarios. But even then, you will run out of memory much faster if you have thousands of goroutines waiting on a timer channel versus tasks waiting on PeriodicTimer. This does not make either choice strictly better than the other as both have their tradeoffs but tradeoffs nonetheless that must be acknowledged (like pros and cons of implicit suspend, stackless vs stackful, etc.).
You can also take the data from the code snippets from the gist I linked and replicate it with current versions of Go and .NET on your own machine. This is the perfect case that illustrates how much memory consumption you will see with massive amounts of mostly-suspended-periodically-calling-a-service Tasks and Goroutines. But you did not and have a history of constructing arguments in bad faith, not actually discussing strengths and weaknesses of a particular language.
Not sure what is the purpose of the link for tasks (which does not talk about cancellation, this one does: [1]) and Go's stack implementation. I'm very well aware of both, which is the driving reason to respond here to salvage the discussion with otherwise wrong claims.
Lastly, the data from 2019 is irrelevant because it uses completely different threadpool implementation and is likely measuring also the one-time cost of JIT compilation for code. .NET has significantly evolved since then and provides much better native compilation[2][3] than Go today, as well as much higher throughput[3][4] code w.r.t GC and JIT for long-running services.
You realize you can change the default memory stack on go routines right? I mean, I’m just going to ignore anything you say going forward as this stalking of you is beyond silly, but at least get things right.
World does not revolve around you, it's an infantile outlook :)
I simply see a discussion that might be interesting and respond to comments related to topics I feel proficient at.
In any case, how many deployments realistically adjust their goroutine stack size? What are the implications of starting with <500B-1KiB default stack (because asynchronously yielding task will use as little as <100B)?
https://karl-pickett.medium.com/benchmarking-a-toy-c-task-vs...
Hell, you can even test things yourself:
https://go.dev/src/runtime/stack.go
For our specific use case C#'s TPL was ok, but it comes with a massive overhead compared to Goroutines. We can have tens of thousands concurrent threads running at the same time at very little CPU usage (which is primarily what we pay for). It’s not that you can’t use async/await tasks to do the same, but they use a lot more CPU and as such is less cost effective for us.
As far as blocking and having meaningful (again meaningful is the keyword) cancellation I encourage you to look to Microsoft and understand the limitations outlined by them in the learning articles starting here:
https://learn.microsoft.com/en-us/dotnet/csharp/asynchronous...