Fiber is better than go's goroutine?

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/14 9:32 AM, Sean Kelly wrote:
> The real tricky part, which is something that even Go doesn't address as
> far as I know, is what to do about third-party APIs that block.  The
> easiest way around this is to launch threads that deal with these APIs
> in actual kernel threads instead of fibers, or try to make the scheduler
> smart enough to recognize that blocking is occurring (or more generally,
> that a given logical thread isn't playing nice) and move that fiber into
> a dedicated kernel thread automatically.  This latter approach seems
> entirely possible but will likely mean kernel calls to gather statistics
> regarding how long a given thread executes before yielding, etc.

I'm not sure but as far as I understand this one issue forces Go code to 
have a strong networking effect (must call into Go code designed 
especially for cooperative threading). That forces a lot of rewriting of 
existing code.

Andrei