[steveklabnik]

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.

[nullwasamistake]

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

[steveklabnik]

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.

[nullwasamistake]

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