Hacker News Reader

Comment by spriggan3 | Hacker News Reader

How does Swift handles concurrency ? does it have CSP with channels, and a select statement ? because if it doesn't it's not going to kill anything.

View on HN

It doesn't right now, you are dependent on grand central dispatch. Adding concurrency features to the language will be a focus in Swift 4.

Here is a document describing the current state of concurrency in the language: https://github.com/apple/swift/blob/master/docs/proposals/Co...

To be clear, that document contains brainstorming by some core Swift team developers. It's neither implemented in Swift nor officially accepted as a guideline for future development.

"The implementations of the thread-safety layer, the thread verifier, and programs that use the three concurrency libraries are available in the concurrency git branch."

"This is a proposal and not a plan of record."

Not only that, the git feature branch, if it ever existed, doesn't anymore.

Oops, thanks, I should've been clearer.

Thanks, I'm going to have to take a long hard look at that and the repo. I've just spent a couple of weeks abstracting over async in Swift [0] and where I ended up looks a lot like that - to the point where some of the primitives have identical type sigs (mainly because the patterns used here are not novel - promise/future, async/await, etc). Be great to see this as a core language feature!

At least now we can see stuff coming, I had just finished writing unit tests for my OAuth library when Apple rolled an implementation into iOS.

[0] I'm aware of PromiseKit and co (and read a bunch of their sources), but I didn't feel like I had a good conceptual grasp on their implementation until I could create something similar and understand how it works and how to use it to solve my actual problems. Often I'll bin my own implementation afterward and use an extant library, so this is almost - but not entirely - quite unlike NIH.

Edit:punctuation

Check out VeniceX[1]. It provides Go-style concurrency. The same group[2] that is working on this is also working on a GCD based concurrency library but the name escapes me at this time.

[1]: https://github.com/VeniceX/Venice [2]: https://github.com/Zewo/Zewo

Yeah, it's very cool stuff! Would just like to add that VeniceX is actually single-threaded, so it's more safe than Go's. It's similar to libuv in that way, but since it doesn't use callbacks it's much nicer.

CSP with channels in Go is just a fancy locking mechanism, something that Rob Pike and co wanted to experiment with, and a marketing feature, of course. Nothing more. They don't really work that well. Their limitations, verbosity and quite complex implicit behavior makes them hard to use for high level things. I think mutexes are more widespread and more encouraged already in Go, than channels. So, idiomatically and in the standard library Go doesn't handle concurrency well at all, on the opposite, it has the worst kind of concurrency - shared memory multithreading. And anything can be better than that. Even a wrapper around synchronous APIs ;)

It doesn't mean, of course, that Swift or any other language will be a Go killer. It means that most people never write complex concurrent programs to begin with and don't really care about good concurrency models. Sadly or luckily, this applies to people, who design languages as well, so concurrency tend to be a hype-driven mess. The only known exception is Erlang, where the whole language was designed to solve concurrency problems.

I agree. I've found Go channels to be disappointing in practice. There's lots of PR but little criticism of something so key.

The fact that they are implemented using mutexes is, from my admittedly limited, non-concurrency-expert perspective, inexplicable. The simplest use case, an unbuffered channel, should be trivial to implement using CAS. There's a bunch of research on implementing robust queues using CAS.

Then there are the various ugly edge cases: Closing a closed channel is an error (now you have to implement your own refcounting implementation if you want to hand out a single channel to multiple consumers), receive on nil channel blocks (means you can't use nil as a signal to mean "I've closed the channel"), etc.

I really like GCD's style of enqueueing concurrent tasks, which I think is a concurrency model that often works more naturally than channels. A major difference between GCD and goroutines is that you can specify what queue to use. I'm looking forward to see what they come up with for Swift.

I think that Go's biggest mistake was making goroutines multithreaded. Libmill takes a much safer approach by making everything still run on one thread (and by taking advantage of libmill, Venice brings a similar scheme but with the added safety).

Built-in, it's threading and Grand Central Dispatch. However there are a shit of good quality libraries available for swift. PromiseKit being the one I'm most familiar with. There are others that offer CSP and channels.

Also Swift 4 will contain it as a native part of the language.

Swift has Grand Central Dispatch (GCD) for running concurrent code

(But only on OS X and iOS)

Yes, currently. But in the link, it states that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries." And GCD (or libdispatch) is part of the Swift Core Libraries :)

Isn't libdispatch fully implemented on Linux and *BSD?

Reply on news.ycombinator.com