Been putting the finishing touches on Bunny's transformation into #fibers PR. One of the major things for me there is visualizing the changes, especially the breaking changes. For example switching from a promise based API to a fibers based API:
Modern current code should run asynchronously if possible and useful. Slowly but steadily, it is being implemented in almost all popular programming languages, including WebDev.
"Now that we’re at the end I want to thank you for reading all the way to the end. I wanted this book to feel like a journey we took together, not like a lecture. I wanted you to be the focus, not me.
I hope I succeeded with that, and I genuinely hope that you learned something that you find useful and can take with you going forward."
I definitely learned a lot! And a journey it has been indeed! This book will be my go-to reference for all things #Async in #Rust!
Phew... One key step closer to replicating & simplifying core https://thi.ng/rstream functionality via just standard async iterables: Just added a mult() base-operator to https://thi.ng/transducers-async [1] which allows splitting a single async iterable into multiple child async iterables (aka subscriptions, aka 1:N splitting), each of which can be added/removed dynamically and individually processed e.g. via transducers, vanilla for await() consumers, and/or used as input for downstream mult()s to construct entire graph topologies (cycles allowed) of async processors etc. Back pressure is handled by waiting for all child subscriptions to deliver the value before consuming a new one from the source...
For @made and others who might have questions about the new https://thi.ng/transducers-async library, I've tried to illuminate the behind-the-scenes approach over here:
Upcoming, a new & simplified implementation of https://thi.ng/csp (currently still only on a feature branch[2]) for building blocks for Communicating Sequential Processes.
Also still WIP only, async iterable support for https://thi.ng/rdom, i.e. in the same way as rstream subscriptions, such async iterables can soon be directly embedded as component/element bodies or attribute values and then perform pinpointed DOM updates each time their value changes...
As I said, async all the thi.ngs...
[1] h/t @sjb3d for an ancient tweet with a similar sentiment & outcome :)
[2] The CSP package too was somewhat deprecated (for similar reasons) and a while ago I added another alternative CSP implementation via https://thi.ng/fibers, but that package too might see some more refactoring/simplifying by switching to async generators...
🧶 Why choose async/await over threads? - notgull.net
「 Smart programmers try to avoid complexity. So, they see the extra complexity in async/await and question why it is needed. This question is especially pertinent when considering that a reasonable alternative exists in OS threads 」
#Swift can be so much cleaner and more concise than #ObjectiveC. Really digging the new concurrency syntax with #ASync and #await for working with #CloudKit. Now if only I could convert my entire project to this. But 16 years of development has lots of legacy code. But I am slowly modernizing some of it and writing new stuff in Swift and SwiftUI.
In our latest development team working agreement someone added the item "If you're going to #Slack someone a question, don't write 'hi' and then wait for them respond, just send the question." Friends, I never felt more seen than in that very moment. #Agile#Async#Software
I'm using the #reqwest crate to call two different APIs. One is working fine, the other I had working intermittently but not sure what fixed/unfixed it.
The issue is that the await doesn't return even though using curl works fine.
Why would await not return after a few seconds when the curl request returns immediately?
As suspected the issue was not in the code I created to use remote web APIs.
The issue was that using the async function which polls the web APIs as a tokio::future was preventing the await on the web request from ever returning, even though the remote web API was responding correctly.
I fixed this by doing the polling of the my async function manually alongside the select! macro which handles the other two futures, all within a loop.