FibJS: Based on V8, uses fibers instead of async | Hacker News Reader

FibJS: Based on V8, uses fibers instead of async

fibjs.org

18 pointsalexbezhan14 comments

As someone who wrote something similar (https://github.com/olegp/common-node) back in the day before async/await, I have to say that I don't see much of a need for this nowadays. The only feature that's still useful that I can think of is the ability to run the same code on V8 and the JVM.

I think this is a hoax/joke?

The performance test is bizarre, and literally nothing in the development guide ever shows anything but single-thread serial code for i/o.

What, exactly, happens if a second user accesses the website while a request is processing?

Also the docs don't explain how fibers are being used -- what is the scheduling strategy? Is there even more than one fiber?

You have to couple it to ImodiumJS which allows calling fibers asynchronously.

Damnit.. I even searched for it =)

It's not a joke. There is no scheduling strategy, since fibers allow only for non pre-emptive multitasking. There may be multiple fibers, but only one running at a time within the same process. If a second request comes in while another is processing and assuming that the first doesn't yield control by doing I/O, for example, then the second request isn't processed until the first one completes. If the first does yield control, then the two may be processed in parallel within the same process, just like with async/await.

There can be several fibers ready to run, e.g. if a mutex or condition variable is being waited on by multiple fibers. You still have to choose which one to run next. If you choose wisely, you might, e.g. be able to free up memory from closures that go out of scope quicker than others.

Think of a data-shuffling pipeline that also updates statistics (in the background): running the next stage of the pipeline is more likely to get rid of lots of memory chunks than is running the statistics code. It also improves pipeline latency, of course. The scheduling definitely matters even for cooperative threading.

You're right and I was wrong to say that a scheduler isn't needed. I assume a fiber scheduler is usually much simpler than a thread scheduler though, since it just needs to decide which fiber to run, rather than how long to run a thread for and where.

The docs are so disingenuous

https://fibjs.org/en/docs/guide/about.md.html

The comparison doesn't do half of what the original did. Bizarre

Is it just me, or does their example of the traditional way of doing those calls user literally the least efficient possible way of writing that code?

Surely using async/await would get you to something nearly as clean as their end-state

Also, V8 is being abandoned very quickly because how poorly it's build quality effects development so that costant flattery of V8 seems to suggest some kind of blinders.

Who is abandoning v8?

bun

Deno, bun. Pgv8.

If you've ever tried to build it, you'd understand why there's suddenly multiple options.

The page is “Copyright 2012-2021”, which would place it around the time that Promises/A+ was just getting started. That code example is a prime specimen of the all-too-common “callback hell” that led to the creation of promises and eventually async/await; what we’re looking at here is effectively an alternate-universe way of solving the same problem.

It sounds like FibJS supports async/await as well, but that just means there are two ways of doing things: I suspect a big reason promises won out is because they could be easily polyfilled into browsers, and a bit part of NodeJS’s appeal was using the same libraries on both sides.

Reply on news.ycombinator.com