4 ms·
Go is worse at _lightweight_ concurrency because each Goroutine is much costlier than each .NET task. Also Go has less pleasant concurrency semantics comparativ
by neonsunset 2y ago
Go is worse at _lightweight_ concurrency because each Goroutine is much costlier than each .NET task. Also Go has less pleasant concurrency semantics comparatively speaking because Goroutines cannot yield a value - you have to spawn a channel on top of spawning a Goroutine or you need to use a wait group or similar. .NET offers better experience for concurrency-centric code at a much lower overhead for code that has light of finely grained concurrent operations.
https://hez2010.github.io/async-runtimes-benchmarks-2024/take2.html https://hez2010.github.io/async-runtimes-benchmarks-2024/tak...
- cyberax 2y agoA million tasks results in 2.5G memory spent (for stacks). This overhead is indeed real, but it is basically immaterial. If you're using that many goroutines, you are going to be CPU-bound unless it's a very special type of workload like a WebSocket dispatcher. In return, you get _normal_ stack traces, and a normal debugging experience. Not a callback hell of async/await. Also no "colored functions" nonsense. Coroutines make sense only for something small and trivial, like the classic tree iterator. And Go now has that: https://go.dev/blog/range-functions https://go.dev/blog/range-functions
- neonsunset 2y ago> In return, you get _normal_ stack traces, and a normal debugging experience. Whatever language you have in mind, it isn't C#. Because all those work perfectly fine there. Please also do a cursory read of what coroutines (stackful vs stackless) in the context of concurrency are. And in Go, all functions are colored, often in ambiguous way due to poor culture of not passing the context where it matters, and goroutines panicking in dependencies that cause uncatchable application crashes. Never change, Go community.