Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: