Hacker News new | past | comments | ask | show | jobs | submit login

Fibers "allow blocking and non-blocking implementations to share the same API"

That's an interesting contrast to Python where the need to use "value = await fn()" v.s. "value = fn()" depending on whether or not that function is awaitable causes all kinds of API design complexity, all the way up to the existence of tools like https://github.com/python-trio/unasync which can code-generate the non-async version of a library from the async version.




But if you are writing framework or library that has to deal with both, its:

    result = fn()
    if isawaitable(result):
        result = await result
And turns out isawaitable is not that fast so things like GraphQL libraries that run above logic thousands of times per request get noticeably slow.


I wrote a bit about that pattern last year: https://simonwillison.net/2020/Sep/2/await-me-maybe/

I didn't realize it had a significant performance overhead though, I should look into that.


Ruby has the same design where async is implemented on top of fibers.


> allow blocking and non-blocking implementations to share the same API

Sounds like an excellent way to create weird concurrency heisenbugs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: