4 ms·

I don't know - this is a language that can't easily handle concurrency. Instead you mess around with dispatchers. And then you're dealing with thread-unsafe str

I don't know - this is a language that can't easily handle concurrency. Instead you mess around with dispatchers. And then you're dealing with thread-unsafe structures, objects, arrays, etc. This is such a critical thing with todays interconnected apps that i have no idea how they did not worry about it from the start. Having had the pleasure of dealing with threads, mutexes, dispatchers, execution-contexts and the like there is no way i'd pick up a language that hasn't evolved in that regard, especially on a server. Even Javascript has this figured out with stage-3 async/await.

donut2d 10y ago
I don't have much experience, but I think the VeniceX packages from Zewo answer the concurrency issues quite well. https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice
- proyb2 10y ago
  and Vapor web framework include Venice.
zepto 10y ago
This is inaccurate. There is no term in either Swift, or the Objective-C runtime named 'dispatcher', which makes it seem like you are unfamiliar with the platform. There are dispatch queues, and the whole purpose of them is to abstract away threads and locks. Using them does not require you to use threads, mutexes or execution contexts. Yes, it would be better if Swift incorporated language level concurrency, but it isn't a priority because the platform provides a good solution.
jaegerpicker 10y ago
As others have said this is misleading and inaccurate. GCD, which will be cross platform as of swift 3, is very pleasant and robust to work with and abstracts the threads, mutexs, and dispatchers away from the developer. PromiseKit and Venice are third party libs that also provide other better concurrency patterns.
- chillacy 10y ago
  Also GCD can be faster than locking with a mutex because it doesn't have to trap into the kernel. So now in my app I tend to protect access to variables with queues instead of @synchronized. The only downside is that it can't replace recursive locks

donut2d 10y ago

I don't have much experience, but I think the VeniceX packages from Zewo answer the concurrency issues quite well. https://github.com/VeniceX/Venice https://github.com/VeniceX/Venice

proyb2 10y ago
and Vapor web framework include Venice.

zepto 10y ago

This is inaccurate. There is no term in either Swift, or the Objective-C runtime named 'dispatcher', which makes it seem like you are unfamiliar with the platform. There are dispatch queues, and the whole purpose of them is to abstract away threads and locks. Using them does not require you to use threads, mutexes or execution contexts. Yes, it would be better if Swift incorporated language level concurrency, but it isn't a priority because the platform provides a good solution.

jaegerpicker 10y ago

As others have said this is misleading and inaccurate. GCD, which will be cross platform as of swift 3, is very pleasant and robust to work with and abstracts the threads, mutexs, and dispatchers away from the developer. PromiseKit and Venice are third party libs that also provide other better concurrency patterns.

chillacy 10y ago
Also GCD can be faster than locking with a mutex because it doesn't have to trap into the kernel. So now in my app I tend to protect access to variables with queues instead of @synchronized. The only downside is that it can't replace recursive locks