Generators instead of fibers

core
1

Fibers seem a hack to me. They are compiled with native code. Have a look at the nasty low level libcoro code in Linux needed by fibers:

So I wonder if there are any long-term plans to replace fibers by generators?

I know that fibers work subtly differently than generators. See this Stack Overflow post Can node-fibers be implemented using ES6 generators?

I don’t understand the whole story. It seems that switching a fiber switches the whole stack while pausing the generator only switches the call stack one level deep. Or perhaps I misunderstood the problem completely. But I understand that this subtle difference would make it impossible to just swap out fibers by generators.

On the Stack Overflow question other people however claimed that they found a solution. Confusing. Are they right?

What do you think? Is it possible to swap out fibers by generators? What changes would this entail to Meteor?

2

From my point of view I always compared fibers with something like (service/web/…)workers, so something more thread-like, only with ‘more’ shared scope. But please correct me if I am wrong! And if thats the case, in any kind, it would not make a lot of sense to replace fibers w/ generators, at least to me.

3

I think generators (ES6) are intent to do iterations. But async/await (ES7) are definitely a replacement for fibers.

I mean, not using fibers at all. I think babel can output async/await transpiled code for both generators ready (node >= 4.x) and not yet ready (today’s browser’s, node <= 0.12) environments.

Fibers played really well on meteor’s mission (in fact, I never liked this non isomorphic server only feature provided by fibers), but we can’t forget to embrace the ecosystem (ES7). Not to say that fibers is a native compiled dependency, slowing down meteor upgrades/adoption of newest node.js releases.

1 Like
4

async/await on both ES5 (node <= 0.12.x or today’s browsers) and ES6 (node >= 4.x) environments

5

Now meteor going full npm and node 4 on the way, it’d be really interesting to get some feedback from core about the plan with Fibers.

Over the last few years of Meteor London meetups the “what the fibers!?” question has come up time and again. It has always felt like that the gains in readability it added for server side code never quite justified the net increase in complexity it adds to the system as a whole, particularly with regards to the mismatch it causes between the functionality of the server and client apis.

6

OH MY

“in the future, once async / await is more supported, we simply get rid of fibres… we’re migrating our code to using this async/await abstraction, rather than using fibers directly”

Also of note: you can use async / await in meteor today! async/await transpiles to fiber code on the server! You can async /await on fibre code or promise code and it’ll just work.

Thanks for a super informative video @sashko @zoltan and @pauldowman

2 Likes