3 ms·

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they ca

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they can be competitive for years (at the very least vs. Objective-C) with only platform-level concurrency support, it makes me wonder whether concurrency is generally better provided by the platform instead of the language for most needs. Conventional wisdom would have it that for a systems & application language designed in 2014, a good concurrency story would be close to job #1.

danappelxx 11y ago
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 https://github.com/VeniceX/Venice [1] https://github.com/Zewo/Zewo https://github.com/Zewo/Zewo
- proyb2 11y ago
  Yes, if Swift team could continue from Zewo and Venice, it will save lot of resources to build from ground up.
Matthias247 11y ago
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.
lobster_johnson 11y ago
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/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co....
- Razengan 11y ago
  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/BNQueue/BNQueue.swift 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 } }
  - lobster_johnson 11y ago
    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.
oleganza 11y ago
Here is my proposal for syntax support for the existing callback+libdispatch patterns: https://gist.github.com/oleganza/7342ed829bddd86f740a#async-semantics 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.

danappelxx 11y ago

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 https://github.com/VeniceX/Venice [1] https://github.com/Zewo/Zewo https://github.com/Zewo/Zewo

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

Matthias247 11y ago

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.

lobster_johnson 11y ago

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/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co....

Razengan 11y ago
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/BNQueue/BNQueue.swift 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 } }
- lobster_johnson 11y ago
  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.

oleganza 11y ago

Here is my proposal for syntax support for the existing callback+libdispatch patterns: https://gist.github.com/oleganza/7342ed829bddd86f740a#async-semantics 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.