[selkin]

> Initially, I avoided Swift because of my previous experience with it […] without native async/await at that time, writing concurrent code compared to Go or JS/TS felt clunky and boilerplate-heavy.

I have to disagree. Async may makes concurrent code easier to write, but also less simple to reason about as it grows. In a complex async codebase, I find it harder to reason about code flow and concurrency.

If the goal is to reduce the cost of executing threaded code, we have a solution in green light weight threads.

If we aim to reduce the cost of maintaining threaded code, I expect async to end up costing more effort in the long run.

[eikenberry]

> Async may makes concurrent code easier to write, but also less simple to reason about as it grows. In a complex async codebase, I find it harder to reason about code flow and concurrency.

Good concurrency should make the code simpler to understand and reason about as it grows. Simply having process/service based encapsulation is a huge win. IMO this is a failing of the async/await abstraction, not concurrency itself.

[selkin]

> Good concurrency should make the code simpler to understand and reason about as it grows.

As an ideal.

But you can only go so simple once you have a piece of data that is read at the same time by many, while also maybe mutated by at least one. And as simple you can get version 1.0, as software grow, it gets new features which necessitate more interactions with that data, which makes synchronization more complex.

[eikenberry]

> [..] once you have a piece of data that is read at the same time by many, while also maybe mutated by at least one.[..]

Dataflow patterns avoid this sort of issue by eliminating shared memory mutation. All data flows through the system by value with mutations only flowing downstream. There are several "Concurrency Patterns" videos by Rob about using these patterns in Go on youtube.

[Citizen_Lame]

But for his usecase, this most likely won't be an issue as he just wants simple audio player.