Go (which I think you're alluding to) has language-level concurrency because its syntax is extremely rigid. Swift's syntax is flexible enough that this isn't needed.

Specifically:

* Support for annotations; the compiler/runtime can be informed about safety and marshaling concerns. * Anonymous function bodies. You can implement Go's "go func() { ... }()" pattern yourself, and a concurrency runtime can implement it. Rust uses the exact same pattern. * Generic iterators/streams. No need for channels as language primitive since you can write a generic channel implementation.

Go is nice, but its language-level concurrency is very much a side-effect of its intentionally impoverished type system. For example, the built-in "chan" type exists because otherwise a generic channel implementation would have to use interface{}, which is not type-safe and would be hell to work with.

Here's what's lining up to become Swift 4.0's concurrency support (all the concurrency models!): https://github.com/apple/swift/blob/master/docs/proposals/Co....

I like this particular example of how easy it can be to make Swift act like it has language-level concurrency features: https://github.com/beeth0ven/BNQueue/blob/master/BNQueue/BNQ...

Some enum and extension magic easily lets you write things like:

  Queue.UserInitiated.execute {
    let url = NSURL(string: "http://image.jpg")!
    let data = NSData(contentsOfURL: url)!
    let image = UIImage(data: data)

    Queue.Main.execute {
      imageView.image = image
    }
  }

That's awesome. Blocks were always my favourite part of Ruby, and I think it's really cool that it has been adopted into Swift and (to a lesser extent) Rust.

I'm not sure if Swift really needs language-level concurrency support. As it stands, you can wrap any C library which provides some sort of concurrency and make it feel like native functionality because of Swift's syntactic sugar such as trailing closures. For example, I'm a huge fan of the library Venice[0] which provides CSP by wrapping libmill (single-threaded like libuv, uses setjmp/longjmp instead of callbacks unlike libuv), essentially providing a Go-level api without language-level support. Its what Zewo[1] is built off of, and what allows all of its api's to be synchronous without any extra effort.

[0] https://github.com/VeniceX/Venice

[1] https://github.com/Zewo/Zewo

Yes, if Swift team could continue from Zewo and Venice, it will save lot of resources to build from ground up.

I think whether to deeply integrate concurrency into a framework or not is quite an interesting tradeoff. Without a preferred concurrency solution (like Swift, C++, Java, ...) users of the language are can leverage from a lot of different concurrency solutions, from real threads to eventloops/Rx and everything in between. However I think in the meantime that this hurts the ecosystem around the language. When some libraries built around primitive 1 (which might require an eventloop or async/await) and others around primitive 2 (M:N scheduled fibers) these libraries might not be easily combinable in your application. Languages with a preset solution (like Go or Erlang) avoid this problem.

Here is my proposal for syntax support for the existing callback+libdispatch patterns: https://gist.github.com/oleganza/7342ed829bddd86f740a#async-...

The idea is to flatten the syntax without change of the runtime model in the same spirit they did error handling: feels like exceptions, but without ugly stack manipulations.