▲ | selkin a month ago | ||||||||||||||||
> 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 a month ago | parent | next [-] | ||||||||||||||||
> 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. | |||||||||||||||||
| |||||||||||||||||
▲ | Citizen_Lame a month ago | parent | prev [-] | ||||||||||||||||
But for his usecase, this most likely won't be an issue as he just wants simple audio player. |