[tannedNerd]

This reads like someone who purposely missed that part of the documentation just to write this article.

I think I would have less hang ups if the author just came out and said I wanted to try using Go for multi-threaded code with Swift instead of trying to make GCD sound so confusing.

[sephoric]

Even so, I'm glad it's been written. I didn't know you could call Go code from C code (new feature since Go 1.5 apparently) or that Swift could access compiled files with these "module map" things. I'm really glad to see they've both evolved to include useful interoperability and play nicely with other things now, and I'm glad this article shows how in a practical way.

[favorited]

> Swift could access compiled files with these "module map" things

That's been the case since it was released – all Swift C / ObjC interop happens at the "module" level. You write a Clang module map (if you're not using a system library which already has one), point the map at the relevant header(s), then you can import that module into your Swift code.

That said, not everything is capable of being imported (variadics, complex macros, VLA structs, and a few others).

[mmjaa]

Indeed .. things have come a long way since I tried to port IPFS to iOS ..

https://github.com/seclorum/ios-go-ipfs

It seems like there's a better way to go about this than my method. I was motivated to do this not because I don't like GCD (I still don't) but because I really like Go and IPFS and didn't think that iOS should be left out of the party.

But, looking at it again, I still don't think GCD is all that great. This seems to have been intentionally designed to be different from the way so many other systems handle the issue - or at least, different enough that its still relatively discomfiting to attempt to port something away from iOS and not just to it ...

[tylerflick]

Exactly. I get that GCD can be pain to work with, but the OperationQueue class wasn't even mentioned as an alternate.