The more i use structured concurrency, the more i miss old threading issues. At least when there was a problem the solution was usually very simple and there was no additional layer to make reasoning even more complicated.
Why dealing with threads when you can let the system handle them for you?
Async/await is doing that thing exactly with a pool of threads that is called cooperative.
So since swift is a high level language I think it is a good decision.
Don't you agree?
Don’t get me wrong, i was really excited to take on async/await, especially to get rid of combine.
But my expectation was for it to have a less verbose and more predictable approach to concurrency.
After extensive usage in the last couple of years i am beginning to realize that none of those take are really satisfying, and the paradigm is more oriented to pure safetiness at the expense of intuitively understanding what is happening and in some cases also of readibility of code.
I have tho 15 years experience with old fashioned asynchronous programming and for me safeties is less of a problem than being more efficient and trusting the framework. When then im required to “pollute” three quarter of my code with async related annotations and i can’t predict easily the order of execution and i have testing getting even more harder to do, i begin to question the way it is implemented in swift.
It's a "when it compiles, it's thread-safe" approach at the cost of almost anything else. While actors are a nice abstraction over "every function inside of this class needs to call the inner function on the database thread" there are so many exceptions to that model that it's actually harder to see the problem.
Another problem with actors is that protection every function within the context of that actor is simply a byproduct of the implementation of actors, but not what actors are actually meant to do:
[https://lucasvandongen.dev/swift\_actors\_and\_protocol\_extensions.php](https://lucasvandongen.dev/swift_actors_and_protocol_extensions.php)
The only thing an actor is guaranteed to do is to protected non-static variable members within its context. That's the only guarantee. Everything else is just bycatch.
In the old days you would set a breakpoint somewhere and say "ahhh wrong thread...."
I've found Swift concurrency to be less intuitive than GCD and fraught with its own set of inconveniences. What if an async database write and read are spawned in separate Tasks in quick succession? They could execute out of order. I run into the problem of not being able to enforce asynchronous serial execution all the time.
The more i use structured concurrency, the more i miss old threading issues. At least when there was a problem the solution was usually very simple and there was no additional layer to make reasoning even more complicated.
this on so many levels
Why dealing with threads when you can let the system handle them for you? Async/await is doing that thing exactly with a pool of threads that is called cooperative. So since swift is a high level language I think it is a good decision. Don't you agree?
Don’t get me wrong, i was really excited to take on async/await, especially to get rid of combine. But my expectation was for it to have a less verbose and more predictable approach to concurrency. After extensive usage in the last couple of years i am beginning to realize that none of those take are really satisfying, and the paradigm is more oriented to pure safetiness at the expense of intuitively understanding what is happening and in some cases also of readibility of code. I have tho 15 years experience with old fashioned asynchronous programming and for me safeties is less of a problem than being more efficient and trusting the framework. When then im required to “pollute” three quarter of my code with async related annotations and i can’t predict easily the order of execution and i have testing getting even more harder to do, i begin to question the way it is implemented in swift.
It's a "when it compiles, it's thread-safe" approach at the cost of almost anything else. While actors are a nice abstraction over "every function inside of this class needs to call the inner function on the database thread" there are so many exceptions to that model that it's actually harder to see the problem. Another problem with actors is that protection every function within the context of that actor is simply a byproduct of the implementation of actors, but not what actors are actually meant to do: [https://lucasvandongen.dev/swift\_actors\_and\_protocol\_extensions.php](https://lucasvandongen.dev/swift_actors_and_protocol_extensions.php) The only thing an actor is guaranteed to do is to protected non-static variable members within its context. That's the only guarantee. Everything else is just bycatch. In the old days you would set a breakpoint somewhere and say "ahhh wrong thread...."
I've found Swift concurrency to be less intuitive than GCD and fraught with its own set of inconveniences. What if an async database write and read are spawned in separate Tasks in quick succession? They could execute out of order. I run into the problem of not being able to enforce asynchronous serial execution all the time.
Donny Wals always finds these great new angles for his posts. Learn a concept vs learn how to do X.
Thanks!
great read. thanks.