swift-async-algorithms VS elmish

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.

For those interested in .NET languages with alternative compilation targets, Elmish (https://elmish.github.io/elmish/) is pretty unique.

We use F# on the front end (instead of TS), and thanks to the Fable compiler (which transpiles F# to JS, Python, Dart, PHP and Rust), most of the benefits of an Elm-style model in the UI can be ported to all sorts of different outputs languages. The rust target is in beta, but its promising because the WASM bundle size stands to be dramatically lower.

While the default is reactivity library for Elmish is React, you can swap in Avalonia/FuncUI (https://github.com/fsprojects/Avalonia.FuncUI) pretty easily as well.

Naturally I’d recommend using a better language such as ReScript or Elm or PureScript or F#‘s Fable + Elmish, but “React” is the king right now and people perceive TypeScript as “less risky” for jobs/hiring, so here we are.

Since you're familiar with React + Reframe, you can try Elmish! You can use F# to write [Elmish](https://elmish.github.io/elmish/) apps. It takes the Elm approach to building apps.

Who’s paying for this? https://github.com/elmish/elmish

Try F# with Elmish.

Maybe elmish could be of interest to you? https://github.com/elmish/elmish

I never tried Elm directly, but I have used the F# equivalent Elmish - super productive idea.

You can also get nested templates, bind inputs, and radios for example by the way don't be scared by the mutable keyword right there is just to show a brief example in a normal situation you would likely be using Elmish

Comet promotes a variation of the Model-View-Update pattern popularized by The Elm Architecture, Elmish, Fabulous and others. The major parts of MVU are: