Comment by bsaul | Hacker News Reader

Comment by bsaul | Hacker News Reader

Parent Full thread

I've recently started to investigate web frameworks for swift, and specially the concurrency part. So just to clarify something : current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.

This type of model is fine and has worked quite well in the past. It is not event loop like node, nor light threads ( like go), nor actors like erlang, but it does work fine. And since swift is fast, it'll probably work just a fine as your python / ruby / node backend.

What we're looking for for the future of swift is something better / safer than that. But my personnal conclusion is that it shouldn't prevent you from building regular webservice api with this language.

> current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads.

Imho that's just the description of event loop(s). There's a central queue, to which you post work (e.g. in the form of function objects or closures), which will get dequeued and executed in a serialized fashion. The thread look like while ((func = dequeue()) != null) { func(); }. That's the event loop.

The difference to node is that you have multiple of these event loops, which are referred to by queue name. In javascript there's only one single implicit loop. If we look at javascript which webworkers we also get multiple loops and queues (one in each worker). However those are more strongly isolated (no shared memory) than eventloops in multithreaded environments.

How much work is expected from the developer point of view? I'd love to have an alternative to Go, but no concurrency for me kills Swift right of the gate for server stuff.

At the moment, it's mostly the framework's job. You write your handler and call the libs for interacting with i/o.

Posting a job ( aka function call) on a queue for async programming is also very very easy.

There's nothing like coroutines or channels though. So you're back to mutex and OS thread constraints in terms of the number of spawnable threads.

Thanks for that explanation... so in short is not ready yet. Go's channels is what makes it seamless. So few choices for solid concurrency today.

Reply on news.ycombinator.com