> if Go can do it, Swift can do it even better.

This might be hyperbole, but if not I'd love to see some examples on how Swift can improve on Go's concurrency patterns.

Swift currently has no language-level concurrency model at all (the only concurrency support available is through libraries such as pthread and libdispatch). However, real concurrency support is on the roadmap for Swift 6 [0] (probably based on some combination of async/await and an actor model), and the core team is expected to release an initial design document within the next few weeks.

[0]: https://forums.swift.org/t/on-the-road-to-swift-6/32862/

It might not offer first class support for green threads like Go, but GCD is an even better imho model for 90% of concurrency needs of the average app:

https://developer.apple.com/documentation/DISPATCH

"concurrency needs of the average app" is different from what Go does well with green threads; this seems like something Swift does notably worse, but well enough that it doesn't annoy you in your use case. I feel like this is a different standard from "if Go can do it, Swift can do it better".

Isn’t that just a bridge to an existing OS level feature? Also is GCD green? (As in light weight, co-operative muti-threading)

>Isn’t that just a bridge to an existing OS level feature?

Yes. A feature well designed for this very purpose.

>Also is GCD green?

GCD tasks are not green threads but they're not direct threads either (even though they're used under the hood). They're more lightweight and much faster to create (than direct OS threads).

> And it's efficient enough for all application / cli etc use cases -- if Go can do it, Swift can do it even better.

If you claim something like this, please obviously back up your claims or in the very least, cite a simple example.

What you're asserting could be said to the initial claim as well. Where are all the examples of why it's so much more complex than other languages.

Swift isn't good for backend services. Linux port is also average ect ...