Are Golang goroutines (relatively) the same as C# tasks?

I keep hearing how GO is the greatest thing since sliced bread for concurrency but so far I haven't seen much proof of that. In fact I haven't found any good synchronizing constructs besides wait groups and channels for synchronization.

Supposedly goroutines should be very lightweight and fast, since they are not an actual thread but an abstraction used by GO.
<br/>That made me think of C#'s Tasks.

Does anyone know, from data or tests being run, not just word of mouth, if goroutines are faster/lighter than C# tasks?

I'm trying to find out if there's any reason or benefit to use GO if I already know C#.

There are significant differences between the behavior of Go goroutines and C# tasks that I would not consider them equivalent.

Common Features

They are both userspace threading systems capable of doing M:N threading (large number of lightweight threads on top of a small number of OS threads).

Differences

• Goroutines can be preepmted. This means that no matter how many compute-bound goroutines you have, you can't block other work from progressing.

• Goroutines can hold locks across I/O. This is disallowed in C# tasks.

• You can control how C# tasks are scheduled, using a scheduler of your own choosing, freely assign different tasks to different pools of threads, or assign priorities to tasks. You can even run all your C# tasks on a single thread.

• Code that runs in a goroutine is just ordinary Go code. C# code must be rewritten to use async / await / Task.

The way I see it, C# tasks are syntactic sugar for rewriting your code as a state machine and capturing state as objects on the heap rather than on the stack. All scheduling is done in ordinary library code on top of an existing thread primitive.

Goroutines are designed to be much closer to OS threads in terms of their behavior (locks, IO, and preemption) although they are not perfect.

It is easy enough to make your C# tasks deadlock if you use ordinary threading primitives to wait for a condition, but the task scheduler has no remaining threads available to schedule the task you are waiting for. That's why you can't await while a lock is held... the scheduler might schedule a second task which ends up waiting for the lock held by the first task.

The big benefit of the C# way of doing things is that you can use your own scheduler. I used this extensively when unit testing. It can be a bit more annoying to write tests for concurrent Go code compared to how easy it is in C#.