This article is full of inaccuracies, I don't think the author really understand the subject. > As Rails continues to replace the usage of threads with fibers

This article is full of inaccuracies, I don't think the author really understand the subject. > As Rails continues to replace the usage of threads with fibers That's not what we're doing... Rails doesn't really use threads anyway. We just introduced an indirection so that the request state can be stored either on thread local or fiber local variables. > An isolation level determines how database tractions are propagated to other users and systems. The author is confusing `active_support.isolation_level` which is either Fiber of Thread with database transaction isolations. The concept is similar, hence why the name was chosen, but it's two very different things. > Ideally, in the foreseeable future, we can expect good performance improvements to Rails I/O operations. Not really no. I/O will still be IOs, you may gain a tiny bit because of the cheaper "context switches", but it's gonna be very marginal for the vast majority of Rails apps. The goal is to allow the community to use fiber based server if they wish, but I (the author of most of these changes) don't except any substantial performance improvement from it.