The second time I've used it in a big commercial project it was used well, and that remains the best codebase I've ever worked with. Super easy to reason about, extremely performant, easily the cleanest asynchronous codebase I've ever seen.

I do believe surrounding tooling is important though. Part of why that codebase was so clean was because it used a framework that integrates very well with RX-Java (micronaut).

That said, I've never worked with await/async in any larger project, so I can't really compare the two fairly.

I think the issue is, the more power you get the more you have to be vigilant and more effort into ensuring the power is used wisely. The first project I joined that used RxJava learned this lesson very painfully.

In my projects I am ensuring some standards on how APIs are constructed and expected to behave so that composing large reactive systems is not getting out of hand very quickly.

Another problem is the steep learning curve for people who learned to mostly copy/paste code from Stack*. You can create very quickly what would normally be a very complex application with just few lines of code of Reactor, but it is not for free -- you still have to understand what it all does and how it all works or you will face consequences at some point.

The codebase I have worked on might be a bit of an edge-case too, as it was used in realtime audio/video communication, so ms-timing, order of async operations and keeping a consistent state were absolutely necessary.

Using Rx for such complex, long-lived business logic is probably a long shot from using it for a cleanly structured SPA for example. I've used a lot of reactive concepts in applications that simply fetched and displayed data and in those cases, I really enjoyed it.

This phrase alone: "data-flows that go through multiple modules" is a very good indication that you broke things down too much, and should have ditched the FRP abstraction on a higher level.

It's better when you use a reasonable level of abstraction and think hard about maintainability of FRP code beforehand.

I had a similar experience maintaining and reviewing an Angular+Typescript application at work. I was fascinated about RX and was looking forward to see it in action.

In practice Angular exposes everything from its internal framework and interfaces as Observables, making RX everywhere the default.

The simplest things became mindbogglingly complex and asking “what does this code actually do” became the most frequent code-review question.

When we were unable to get the application stable, I made a renegade effort to eliminate all Observables and replace them with standard, well-understood Promises instead.

The result was fewer lines of code, clearer code, fewer bugs and more tests as bootstrapping/mocking a Promise-based API is significantly less effort than doing the same for its Observable-based counterpart.

It was a terrible experience all over and realistically (given the choice) I’ll never touch an Angular or RxJS based app ever again. My team will just touch React for any new development from now on.

He did the same thing: ripped out all the observables and replaced them with Promises and async/await. He loves how much it simplified things.

Wow. You would have been better off ditching Angular entirely, or sucking it up.

Unfortunately I didn’t have the time nor management buy-in for doing that (a full rewrite), so instead I went for the second best option, which was making the code we had at least manageable.

As for the “complexity”, I largely solved this problem by limiting dimensionality of stream handling to 1, and chaining streams via explicit function calls so that I was never map/flat mapping stream to stream to stream etc.

This made everything much easier to understand in my projects, and also test etc.

But you’re right as now that async/await is in Swift proper I’m not sure it makes much sense anymore. There’s still some functionality I need that seems external (looks like async sequence might help once I can use iOS16 as a min spec?). Beyond the basic stuff, it’s essential that I can:

1) Define explicit timeouts that throw typed errors for every step of the async process

2) Have the ability to queue up an array of async operations (each with their own timeouts), dispatch them in a serial queue, then buffer their results to emit a single array, itself with a global timeout

3) While doing all of the above, I need a way to terminate async actions “in flight” upon receipt of some signal, so that a long running async queue can be aborted if necessary

Once all of the above is possible I’ll probably go back and rip out Rx (Combine) in a few years for a pure async-await implementation, but that will take forever

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

Async / await's backport no longer causes crashes in Xcode 13.4, but it does have the downside of being the Swift 5.5 runtime, which has several unfixed issues, unfortunately.

any links for this? im curious as im using async/await on xcode 13.4 currently.

Same experience. Functional/declarative code is more elegant, but a small change in desired behavior might require completely different structure of the code (or an ugly hack). Meanwhile imperative code changes much less even if it's less elegant.

I agree the code can balloon in size, and gets a bit hard to organize at some point, but the self-documenting aspect of it is amazing.

I combine an FRP framework (bacon.js) with Ramda.

I’ll admit I’ve had trouble working with things like React because I’m so used to wiring everything up explicitly and there being no “magic” behavior.

The explicitness is probably what makes it seem so unwieldy as the code/team scales

A single block of statements that transform and handle data in a specific way is indeed almost self documenting, which is really cool.

However, how did this work for you with more complex combinations and transformations?

For example, our codebase had one module that took inputs from multiple different sources (low-level network handling based on a library) and generated a consistent state out of them. To keep the code performant, we introduced some intermediary values, so that certain transformations had to be run less frequent. (this was necessary)

In the end, we ended up with a ~500LoC module. I wrote the same later with async/await and split everything into ~20 functions, which worked really well. The reactive version however, was just a bunch (~15) blocks of transformations, which were somewhat self explanatory in themselves but it was almost impossible to trace the flow of data through the whole module without drawing it up.

Even just naming a block (a function name) helped a lot. Sure, you can document blocks of reactive code, which is what we ended up doing but I felt like the self-document aspect fell apart when I had to write a sentence above every block as to why this intermediary transformation is necessary.

Because of the enforced formality of how data is flowing around, the ability to split these streams up is trivial in a way that was a revelation to me. In the past, I'd be far less confident that I was going to mess up something unintentionally, to the point where I would maybe not bother.

And yeah, I think it's totally valid to take larger blocks of streams/transformations and wrap in a named function that takes a stream and returns a stream.

Over the years I've gotten out of the habit of always using FRP for every problem. There are many cases where async/await is totally fine and simple. I still always use Ramda, which gives me the same self-documenting qualities (which is really a function of the strictness of FP, not so much the R in FRP, now that I think about it).

But whenever I have to coordinate multiple inputs with different time delays (i.e. multiple AJAX requests or UI input) or process a bunch of data where each item creates its own stream of fetching and processing, the "reactive" bit is extremely handy.

the other part is the UPDATE from the ui to the model, again this can be handled by simple callbacks and refresh the ui again with promises

there are some nice features of these libraries but most of it goes unused because most apps don't actually need all that power/complexity (sadly i suppose)

lastly, (ime) many devs also don't seem to know how to program data flow in a single direction which gets really hairy because now everything is reacting to everything and fixing one thing breaks another....

The pool table is pretty fun to model. You've got events, which are collisions, and you've got an evolving state that you can sort of fast-forward through thanks to elementary physics. if you want to sample at a given time, you can. You can calculate out the time to the next event (collision with another ball or bumper)

For me, when I got to multiple objects interacting at different times it got really tough to store the state of the world. (like after the break) I didn't try to support angular momentum - but it would have been fairly straightforward to add.

What I've been thinking about lately, is algebra driven design https://algebradriven.design That'd really help with nailing down the data structures and operations on them. That book has a couple of really gnarly sequenced state with constraints examples, that came from real production code.

There's no closed form solution to some problems (a lot! most problems!). So I think really nailing down a data structure, and providing operations on that data structure are essential. You, well, I need to create an environment where I can create tactics for solving special cases, without that code for the tactic getting smeared all over the code base.

I'm a dilettante, I've got very little experience on the JS side of things. But from pure Haskell, I'm a reasonably sophisticated amateur. So take my opinion in that context.

I think the automated tooling for finding laws presented by Sandy Maguire really have a lot of potential for Locking down those interactions - and opening up new ways of decomposing those interactions, to make more sophisticated descriptions of interactions. I'm not clever enough to find a closed form, but given some state and a time delta, I can work out a bunch of special cases - the interactions. Keeping that tidy is tricky. That algebra approach seems really promising.

Again. I'm a dilettante. Take my opinion in that context. There are probably horrible corners where all this falls down. Anyway, the day is starting and it's almost time to go wrestle yaml.

Consider doubleclick. After a click, rather than pausing for 30 frames to see if a second click eventually shows up, you can act immediately, and if there's later a second click, retract and rerun with a doubleclick event.

With incremental speech recognition, interpretation of past words can change as a sentence progresses, so "Launch the missiles!" can replay as "Lunch is mussels! In butter!".

Keyboard and ml-based visual tracking have very different latencies. So when combining them (eg, which finger pressed the key, where on the keycap, and what were any other vision-derived key modifiers), you can pursue a guessed-at transition immediately, and then correct if needed when tracking finally coughs up the hand pose.

Edit: Hmm. Well... having "retractable state transitions". "Algebra" has other implications. Edit edit: s/reversible/retractable/ - sorry.

It's never going to be easy, and somebody has to pick the "right" answer. With more structure, you can get more consistency. I may not like the answers, but they're consistent answers and so I can reason about them.

Reversible state transitions is a whole other bag of mixed metaphors. But I'd still say, more structure makes it consistent, and then you can reason about it, and then you can maybe solve some of those cases.

Things you can do:

* Use static typing. If not possible, use type annotations or proper pattern matching with a consistent structure (e.g. {:ok, val} | {:error, :reason} in Elixir).

* Keep abstraction at a reasonable level, do not abstract things simply because they might become useful.

* Wrap all values that flow in streams in custom data structures that can easily be expanded. Never (unless you're absolutely sure it never changes) use primitive types.

* Use FSM or any kind of modelled sequence to document what a module does (we ended up having mermaid diagram syntax as comments in some of the most complex modules)

* Make sure the language/library you use has good support for testing and especially debugging. Lots of FRP libraries don't or their implementation works against the design of the language which leads to all kinds of odd behaviours.

Things to be aware of:

* FRP enthusiasts often tout that you can use the same flow of logic across languages that provide FRP libraries. Yes, you kind of can but all the functions are named different, have different interfaces and it's been a huge mess for us.

* If you interface with libraries that rely on strict threading (e.g. C libraries using pthread), strap in for some pain. FRP libraries often do what apple does with GCD in where they kind of abstract threading away from you into queues, which works fine if you stay in the FRP world but falls apart when interfacing with thread sensitive code.