However I would still lean towards Swift concurrency, even if it’s less powerful and more lazy.
The reason is as you mentioned compiler integration. I’m not necessarily talking about data races checks, but global help of the compiler writing asynchronous code.
Also, writing asynchronous code with Swift concurrency feels like writing the synchronous code we all already know.
The overhead, or even paradigm shift with Rx, is much less pronounced.
It’s not a silver bullet but I’d default to Swift concurrency, especially for beginners.
Good point Tarek, yes, the learning curve is very steep for RxSwift unfortunately. But it does model your problem better, most of the time, and gives you way more power if you need to.
I'd say for a new developer async/await is a good start but they eventually should learn about reactive programming as they hit the limits of the "easy stuff".
Just like new devs should start with MVC/MVVM but learn more advanced stuff as those reach their limits.
This is genuinely one of the worst articles I’ve read, not just recently, but ever. I don’t even know where to begin explaining why, because it’s just that baffling. In the comparison section, you’re treating RxSwift like it's the built-in, official tool, while portraying async as some random third-party solution.
And then there's this quote:
"In reality though, for over 15 years of me building iOS applications, I have never ever encountered a situation where data access over different threads was a problem. Usually, if you’d get to that point and start having issues with thread data access, race conditions, etc., it’s a symptom of a larger architectural problem rather than an 'async problem to solve'."
I honestly don’t even know how to respond to that. You’ve never had shared state that needed to be updated from multiple places? Never? What kind of miraculous architecture are you using that just completely sidesteps all of that?
And then you say:
“Just purge them and re-architect your data access and this will solve your problem, not an actor bandaid from Apple.”
Calling actors a bandaid? I don’t even want to comment on that.
Those are great points Alex.
However I would still lean towards Swift concurrency, even if it’s less powerful and more lazy.
The reason is as you mentioned compiler integration. I’m not necessarily talking about data races checks, but global help of the compiler writing asynchronous code.
Also, writing asynchronous code with Swift concurrency feels like writing the synchronous code we all already know.
The overhead, or even paradigm shift with Rx, is much less pronounced.
It’s not a silver bullet but I’d default to Swift concurrency, especially for beginners.
Good point Tarek, yes, the learning curve is very steep for RxSwift unfortunately. But it does model your problem better, most of the time, and gives you way more power if you need to.
I'd say for a new developer async/await is a good start but they eventually should learn about reactive programming as they hit the limits of the "easy stuff".
Just like new devs should start with MVC/MVVM but learn more advanced stuff as those reach their limits.
This is genuinely one of the worst articles I’ve read, not just recently, but ever. I don’t even know where to begin explaining why, because it’s just that baffling. In the comparison section, you’re treating RxSwift like it's the built-in, official tool, while portraying async as some random third-party solution.
And then there's this quote:
"In reality though, for over 15 years of me building iOS applications, I have never ever encountered a situation where data access over different threads was a problem. Usually, if you’d get to that point and start having issues with thread data access, race conditions, etc., it’s a symptom of a larger architectural problem rather than an 'async problem to solve'."
I honestly don’t even know how to respond to that. You’ve never had shared state that needed to be updated from multiple places? Never? What kind of miraculous architecture are you using that just completely sidesteps all of that?
And then you say:
“Just purge them and re-architect your data access and this will solve your problem, not an actor bandaid from Apple.”
Calling actors a bandaid? I don’t even want to comment on that.