It is best to treat the linked paper (Fibers under the magnifying glass) as a review of some implementations of fibers and not a repudiation of fibers in genera

It is best to treat the linked paper (Fibers under the magnifying glass) as a review of some implementations of fibers and not a repudiation of fibers in general. In particular, for this paper to apply to golang, several things would need to change : Memory footprint : It says fiber user stack is 1 MB and so fibers have comparable memory footprint to threads. This is not true for goroutines which typically use a 4K stack. Context switching overhead : gives numbers for architecture, but goroutines do not use the expensive switching instructions listed in the paper. Instead golang basically saves just the PC, SP and DX registers, significantly reducing the overhead. Dangers of N:M model : The dangers mentioned of corrupting memory etc is specific to C++ libraries and do not apply to golang. Dangers of the 1:N model do not apply to goroutines either. My conclusion from the paper is as follows : Fibers are bound to fail as an OS feature, or as a library. To make fibers work you need to do what golang does i.e. make it part of the language with compiler support to reduce the context switching overhead and the memory footprint. You will however, pay a price in higher FFI cost. That may be a tradeoff which may or may not work for you, depending on the nature of your application.