Fiber Concurrency(honeyryderchuck.gitlab.io)
honeyryderchuck.gitlab.io
Fiber Concurrency
https://honeyryderchuck.gitlab.io/httpx/wiki/Fiber-Concurrency
11 comments
I have no idea if this is for a specific language, a framework, a plugin system .. or what. And I'm not able to say anything useful from the page or from the title of the post.
It'd be helpful to at least set the premise for those of us on the outside.
It'd be helpful to at least set the premise for those of us on the outside.
I am kind of awaiting some news about more breakthroughs in DWDM technology and clicked through thinking this might be related. All I could tell immediately was that it was code of some description. I really detest when higher level stuff steals terminology from lower level protocols. I feel like they could have found a better term than fiber.
To be fair, "fiber" is a pretty well known term in the context of concurrency. The post author did not make it up.
In cases like this it helps to navigate to the homepage of the website. With one click on the header link, you find out that this is about Ruby and some http server.
It's Ruby, if that's helpful.
Glad I'm not the only one
I'm glad someone is working with Async Ruby.
It's quite exciting to see how much movement there has been in Async ruby. It's not a silver bullet for traditional Rails-like apps, but it's a whole new frontier for Ruby, and is particularly timely and helpful for LLM integrations.
It's also been done in a way that is transparent and practically colorless (in contrast to async/await), AND is competitive performance wise with the big dogs.
I expect it to gain in popularity over the coming years.
It's also been done in a way that is transparent and practically colorless (in contrast to async/await), AND is competitive performance wise with the big dogs.
I expect it to gain in popularity over the coming years.
Ruby's standard library was not littered with too many sync helpers, so making them fiber capable without much standard library effect is a big win. In Python, explicit coloring is required and it's easy to block your asyncio coroutines with sync calls. In .NET, it is nice that tasks can be blocking or not, but there is one fixed global static thread pool for all tasks and so one is tacitly encouraged to do CPU bound work in a task (granted CPU bound fibers are an issue in Ruby too), not to mention issues with changing the default scheduler. In Java, virtual threads take a Ruby-esque approach of letting most code work unchanged, but the Java concurrency standard library is large with slight potential incompatibilities.
Ruby is both 1) lucky it did not have a large standard library of thread primitives to adapt, and 2) smart in that they can recognize when they are in a fiber-scheduler-enabled environment or not.
Granted that lack of primitives sure does hurt if you want to use concurrency utilities like combinators. And at that point, you reach for a third party and you're back in the situation of not being as portable/obvious.