Hacker News Reader

Comment by nullwasamistake | Hacker News Reader

Fibers are way better than async. Go has them and Java is working on it with project loom. It's a slight performance disadvantage (maybe 2%) but light-years easier to work with.

Languages with fibers figure ou execution suspend points and physical core assignment for you and abstract it all away. So physically they're doing the same thing as async, just without all the cruft.

Rust decided not to go with fibers to avoid having a runtime. I still disagree with this because they already do reference counting, not every worthwhile abstraction is zero cost.

View on HN

> Rust decided not to go with fibers to avoid having a runtime. I still disagree with this because they already do reference counting, not every worthwhile abstraction is zero cost.

Refcounting is a library feature, does not require a runtime, and has no impact on code not using it.

Fibers is a langage feature, does require a runtime, and impacts everything.

Rust actually stripped out its support for fibers as its community moved its usage downwards the stack. In much the same way it stripped out « core » support for GC/RC (the @ sigil) or internal (smalltalk/ruby-style) iteration.

The difference with reference counting is that you only get it when you actually use it, but a runtime included by default does not have this property. And having an "opt-out runtime" doesn't fit the bill either; we tried that too.

(I'd also be very skeptical of the 2% figure; where did you get that from?)

Remember, "zero cost" means "zero additional cost", everything has a cost.

2% is from Quasar, a Java fiber library. Some simple benchmark compared it to async code.

Now that rust has async, couldn't they make fibers an opt-in replacement for threads? Your libraries use async, but you can handle those calls with fibers. Fiber support is compiled into your code but not the libraries

Interesting, I wonder what the details look like. We saw fairly big differences in Rust.

> Your libraries use async, but you can handle those calls with fibers. Fiber support is compiled into your code but not the libraries

We tried this! Making the attempt is actually one of the biggest reasons that we decided to remove green threads from Rust; it brought in tons of disadvantages and no real advantages.

I understand why you didn't, but async brings a whole new opportunity to try! At least in library form.

Fibers are great because you can pretend they're threads. Everyone knows threads. Async is a legit PITA even if you're familiar with it. And the local state stored for a fake thread is often useful. When doing async I find myself frequently building hacky hashmaps to hold local variables values. websocket code is a good example of worse-case. 20k ongoing connections held by async (1 thread per core). It's a nightmare in everything except Vert.X Sync (fibers in Java) or maybe Golang and Erlang.

With fibers you get to keep all your local variables and "pretend" threads actually exist. It's a huge boon for productivity in the few languages where it's possible

Reply on news.ycombinator.com