A fiber's stack is allocated on demand. The fibers aren't doing much
in your test so their stacks stay small but in a real application,
each fiber's stack size will be anywhere from a few 10 kBs to up to 1
MB (the limit on x64).
That means those 8,000 fibers can use up to 8 GB of memory. That's
not a strictly theoretical upper bound either; many operations in V8
use liberal amounts of stack space, like parsing JSON, string
manipulation, regular expressions, etc.
A second gotcha is that fibers are implemented as mostly weak
persistent objects that require a special post-processing step in V8's
garbage collector. You probably won't notice it in short-running
tests but in long-running applications, you may see a significant
uptick in time spent inside the collector.
If you're targeting v0.11, generator functions let you do most of what
node-fibers can do at a lower overhead per coroutine. That's not to
disparage node-fibers, by the way. I quite like its simple
concurrency model and its rather ingenious implementation.