swift-async-algorithms VS websocket

Last weekend, I started reading up on Swift Concurrency through the use of async-await, actors, etc... I really liked what I read and thought of converting my current code to use these new Swift Concurrency tools and ditch the GCD. I used continuation to convert all methods with completion handlers from the Device class to async throw methods and turned Device into an actor in order to protect some members from race conditions. Once more, I am faced with the issue of calling the async methods of the Device actor one by one (waiting for each ones completion before starting the next one). I spent a lot of time thinking on how to do this and came across a number of useful references such as this one and this one. I tried to think of ways of implementing such a channel in my controller class, to guarantee sequential execution of different tasks that require the underlying library, but I'm facing a few issues with this approach:

AsyncStreams also now has the associated AsyncAlgorithms library https://github.com/apple/swift-async-algorithms which covers a lot of the Combine features (debounce, merge zip etc.)

You might find the treasure trove known as Swift Async Algorithms and look at their test suite.

https://github.com/apple/swift-async-algorithms

Requires Xcode 14, which is still in beta and cannot push to the App Store.

Also, Apple fucked their back port badly. It’s supposedly fixed now, but if you built an app that used async/await anywhere in Xcode 13.X and a user installed running iOS 12/13/up to 14.5 they’d crash on launch.

So I personally wouldn’t trust it, and instead just push to raise your iOS minimum. I’ve had no problems requiring iOS15 in my projects over 1M installs

Asynchronicity is only one aspect of Functional Reactive Programming. You’re comparing single values vs. multiple values. AsyncStream is a better analog, but I’m pretty sure you still need to bring in swift-async-algorithms to have an apples-to-apples comparison.

The official reason is here: https://github.com/elm-lang/websocket

I believe it's quite possible to support websockets with the current language features, though, and I hope that websockets will be ready for Gren along with the 0.2.0 release in december.