The linked post talks about concurrency not being a focus until Swift 6 at the earliest. Personally, I don't want to make a commitment to server-side Swift until after that dust has settled.
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.