from Hacker News

Writing Apps in Go and Swift

by youngdynasty on 1/29/19, 7:17 PM with 61 comments

  • by iainmerrick on 1/29/19, 8:35 PM

    I still find it hard to write maintainable multi-threaded code for macOS or iOS [...] without having to worry about the minutiae of parallelism (threads, semaphores, locks, barriers, etc.).

    I find this surprising, as GCD does insulate you from that low-level stuff. When you need to work with mutable data, just create a dispatch queue, and only ever access the data by dispatching a function to the queue. Both Swift and Objective-C have friendly syntax for anonymous functions that makes this lightweight and easy.

  • by hellofunk on 1/29/19, 8:34 PM

    > Give Emporter a try and let me know how it compares to an Electron app.

    I don't see how this technique is comparable to Electron. The article does not describe anything related to a cross-platform user interface, which is what Electron addresses. You can write non-UI logic that is cross-platform in half a dozen mainstream languages and another dozen less popular ones. That's not a big deal. It's the UI component that is harder to achieve, and that is what Electron offers.

  • by alexashka on 1/30/19, 2:36 AM

    Just wanted to say that module maps are absolutely not necessary to have static libraries (.a file author compiles his go program to) in your project.

    All you need is an objective-c bridging header where you do an #import "name_of_header_.h" for every header. After that, the headers are visible to all of your swift code. It's no different than mixing objective-c and swift, except here you're mixing your language of choice, compiled to callable C functions inside a static library.

    To recap - drag .h and .a files the same way you have .swift files into your xcode project. Add a BridgingHeader.h file, go to it, fill it with #import "name_of_header.h" statements. Lastly, the project needs to know you're using a bridging header, that's done in the project target's Build Settings tab, under "Objective-C Bridging Header" you need to have the value set to the filename you chose for your bridging header.

    This is not unique to calling Go in Swift btw - any language that can be called from C, can be called from Objective-C, and therefore Swift. One thing to be aware of is memory management - unless you're passing things by value (copying), making sense of when things can be safely deallocated across languages is non-trivial.

  • by sshb on 1/29/19, 9:48 PM

    Go has great crypto library, so I've wrapped it for use with Swift: https://github.com/lastochkanetwork/EasyPGP

  • by benatkin on 1/29/19, 9:15 PM

    Heads up: you made this error at least twice, once in the article and once in the repo. https://brians.wsu.edu/2016/05/31/complement-compliment/ It's complementary instead of complimentary. The word "complimentary" is rarely used, but could be used if you were to mention books related to complimenting people.

  • by coldcode on 1/29/19, 8:36 PM

    I don't find GCD difficult to write for, maybe if you are used to Go it is different enough. Not sure what exactly you would use Go for in an iOS/Macos app unless maybe you have a Go framework you want to include.

  • by saagarjha on 1/29/19, 8:41 PM

    Swift Strings can transparently map to UnsafePointer<CChar> when necessary; is there a reason why this doesn’t work in this case?

  • by onderweg on 1/31/19, 2:54 PM

    I found your article particularly interesting, because lately I've been experimenting with calling Swift from Go.

    The approach is based on the same principle: cgo as bridge between Go and a C library. The C library is build by the Swift package manager. Blog post on Dev community with details:

    https://dev.to/gerwert/calling-swift-from-go-5dbk

  • by tptacek on 1/29/19, 9:36 PM

    How well does this work? Can you call a Go library function that spawns goroutines?

  • by axaxs on 1/29/19, 11:21 PM

    Thanks for sharing this! As someone who writes in Go every day but stopped following it a while back, I had no idea you could even call Go from C much less Swift.

  • by bunnycorn on 1/29/19, 10:59 PM

    Someone that doesn't know how to write Swift, tries to find faults at all costs.

    Go, horrible as it is, doesn't lack cultists.

  • by gcbw2 on 1/29/19, 10:20 PM

    I am go ahead and say it: Go is a replacement for Perl. It is nice for process and machine administration automation. Can you write your app in go? yes. Could you also write your app in perl cgi? sure. Did many people wrote perl cgi apps? yes. did they regret it. yes. Will people writing apps in go will regret it? who knows. Probably yes.

    This comment is not about the language per-se. it is about the current goals of the people with money and weight behind the language right now. I guess the regret will come or not if those goals keep or change.