To answer this quest properly we need to make a benchmark test, to get the real results and compare them, but we can thinking a little about it.

First of all, libuv has a pool of threads to deal with the async operation but is not an infinity pool (if I am not wrong by default the libuv has 4 threads) and each thread can handle one async operation per time.

On the other hand, Golang uses the "green thread model", where each goroutine is an isolated process and handles one operation per time. Theoretically, you can spawn how many goroutines you want per OS Thread.

Each runtime has pros e cons and maybe we can figure out which runtime is better, but I think the real problem is "how will we manage the horizontal scalability of our application". We need to choose the runtime based on our deployment strategy and our team's knologment.

I think I know part of the answer. I tried to summarize my understanding of the differences, in order of importance, between asyncio tasks and goroutines:

1) Unlike under asyncio, one rarely needs to worry that their goroutine will block for too long. OTOH, memory sharing across goroutines is akin to memory sharing across threads rather than asyncio tasks since goroutine execution order guarantees are much weaker (even if the hardware has only a single core).

asyncio will only switch context on explicit await, yield and certain event loop methods, while Go runtime may switch on far more subtle triggers (such as certain function calls). So asyncio is perfectly cooperative, while goroutines are only mostly cooperative (and the roadmap suggests they will become even less cooperative over time).

A really tight loop (such as with numeric computation) could still block Go runtime (well, the thread it's running on). If it happens, it's going to have less of an impact than in python - unless it occurs in mutliple threads.

2) Goroutines are have off-the-shelf support for parallel computation, which would require a more sophisticated approach under asyncio.

Go runtime can run threads in parallel (if multiple cores are available), and so it's somewhat similar to running multiple asyncio event loops in a thread pool under a GIL-less python runtime, with a language-aware load balancer in front.

3) Go runtime will automatically handle blocking syscalls in a separate thread; this needs to be done explicitly under asyncio (e.g., using run_in_executor).

That said, in terms of memory cost, goroutines are very much like asyncio tasks rather than threads.

C# Task is similar to goroutine in the sense that it is also an abstraction on top of physical threads.

At an extremely high view, yes, they can be similar.

However, it is considered a bad idea to do blocking I/O inside an async Task because "the entire thread will be blocked, causing deadlock".

Blocking doesn't necessarily cause deadlocks, but blocking will block the calling thread until the task completes. That's the whole point.

Can't the C# runtime do something similar to goroutines to suspend the blocked async Task and free the physical threads to run other async Tasks?

An async method can just use await to get the behavior you want. Blocking is specifically for blocking threads. Conceptually, goroutines are sort of like making every method async and implicitly using await everywhere.

In the more general case of the C# runtime doing something similar to goroutines for any blocking: the C# runtime cannot easily do this because of backwards compatibility. There's also a lot of legacy code that depends on "special threads" (UI threads, COM STA threads, etc) where a green threading / coroutine approach would be more difficult. Go has mostly avoided backwards incompatibility concerns by just creating an entirely new ecosystem.

Goroutines and async/await are different approaches to asynchronous programming. Under the hood you have P processes M CPU cores and G coroutines. Your language runtime operates them - checks when one should be stopped (unscheduled from real processes and thus CPU cores) and others should be scheduled to cores.

What approach is better? It depends on developer. As for me async/await has more syntax sugar, goroutines is more explicit in terms of programming. So first can be more concise, second - easier understandable in complex cases like select {..} and so on.

Making value judgements is always a tricky thing so I'll highlight 3 differences. You decide whether they fall into the "pro" or "con" bucket.

1. While both Go and async allow you to write async code in a straightforward way, in .NET you have to be aware which part of your code is async and which one isn't (i.e. you have to explicitly use async/await keywords). In Go you don't need to know that - the runtime makes it "just work", there is no special syntax to mark async code.

2. Go design doesn't require any special code in standard library. .NET required adding new code to the standard library for every async operation, essentially doubling API surface for those cases e.g. there's new async http download API and the old, non-async http download API has to remain for backwards compatibility.

3. Go design and implementation is orders of magnitude simpler. A small piece of runtime code (scheduler) takes care of suspending goroutines that block on system calls and yielding to sleeping goroutines. There is no need for any special async support in standard library.

.NET implementation first required adding the aforementioned new APIs. Furthermore .NET implementation is based on compiler rewriting code with async/await into an equivalent state machines. It's very clever but also rather complicated. The practical result was that the first async CTP had known bugs while Go's implementation was working pretty much from the beginning.

Ultimately, it doesn't really matter. async/await is the best way to write async code in .NET. Goroutines are the best way to get that in Go. Both are great, especially compared to alternatives in most other languages.

The chief difference is that Go runtime tightly couples scheduling of the goroutines with I/O which basically works like this: if a goroutine is about to block on some I/O operation or on a channel operation, the scheduler suspends that goroutine and re-activates it once it knows the original I/O or channel operation can now proceed. This allows writing Go code in purely sequential manner—without all the callback hell and "futures"/"promises" kludges, which merely wraps callbacks into objects, and also without async/await machinery which, again, merely couples compiler tricks with plain OS threads.

This stuff is very good explained in this classic piece by one of the developers of the Dart programming language.

Also see this and this.