
Writing Apps in Go and Swift - youngdynasty
https://youngdynasty.net/posts/writing-mac-apps-in-go/
======
iainmerrick
_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.

~~~
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).

------
hellofunk
> 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.

~~~
youngdynasty
Thanks for your feedback. Honestly, I was just being sassy. It probably is
like comparing apples to oranges. This technique does not concern itself with
a cross-platform interface. It only makes it possible to keep the logic cross-
platform so that the "only" difference is the UI implementation, which can be
done using native SDKs.

------
alexashka
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.

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

------
benatkin
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/](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.

~~~
youngdynasty
Thanks!

------
coldcode
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.

~~~
mmjaa
I consider GCD to be a bit of a smell - not because its difficult to write
for, but rather because its difficult to port such code elsewhere. And really,
this seems to be the only rationale for Apple having maintained it as a
component of the architecture for iOS - to be relatively different, or just
different enough, from other systems to dissuade porting the code elsewhere.

~~~
almostdigital
[https://github.com/apple/swift-corelibs-
libdispatch](https://github.com/apple/swift-corelibs-libdispatch)

~~~
mmjaa
Sure. The solution to not wanting to be dependent on Apple's software is .. to
use more of Apples software.

Not really rational.

~~~
iainmerrick
It’s open source. You can use it on Linux rather than being tied to MacOS or
iOS. What’s your objection?

~~~
mmjaa
Lets try this a different way. Whats so great about GCD that other processor
resource management systems get so wrong, that using GCD is the only thing
that makes sense to you?

(Hint: its koolaid, kid.)

~~~
iainmerrick
It’s not a memory management system.

~~~
mmjaa
Right, brain fart on the train. But the point still stands, why should we use
GCD when there are other more portable means out there - which are also
supported on iOS - to do the same thing? It's just different for the sake of
being different.

~~~
iainmerrick
Wikipedia says GCD and Go are the same age (both released 2009). Is Go also
different for the sake of being different? Why is Go good and GCD bad?

I imagine we’re not going to convince each other of the technical merits, but
I personally think GCD is a very nice programming model. I’m less of a fan of
Go but plenty of people love it so clearly there’s something there. There’s
room for both.

It’s a valid criticism of a lot of Apple tech that it’s very locked down, but
given libdispatch is open source (as are the Clang changes to support block
syntax in C) I don’t think that criticism is fair here.

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

------
onderweg
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](https://dev.to/gerwert/calling-swift-from-go-5dbk)

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

~~~
youngdynasty
Yes! I've shipped an app, on the Mac App Store, which uses Go in a non-trivial
way (including spawning goroutines). The link is in the article.

------
axaxs
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.

------
bunnycorn
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.

~~~
saagarjha
I don't see the author pointing out any faults in Swift. There's a passing
comment about GCD being complicated, which I personally disagree with, but
this isn't specific to Swift.

------
gcbw2
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.

~~~
axaxs
They couldn't be further from each other. Just from browsing code, they are on
opposite ends of the spectrum. Go is easily readable, but at the cost of
brevity. Perl is -typically- unreadable, with a lot of one liner magic. If you
are stating merely can a person write a web app in both, well, I think that
goes for any language in existence.

~~~
gcbw2
I know. Perl was all that at the time. daunting! modern! no compiler OMG! text
transformation on the code itself! it was the bee knees.

All that Go delivers today, over the medium, is very similar to what perl also
delivered yesteryear, on top of yesteryear medium. But also like perl, it is
being born from a bunch of old unix system engineers :)

~~~
ptx
Are you sure you're not confusing Go with some other language?

> daunting!

Go is often praised for being simple.

> modern!

...and criticized for being _too_ simple, ignoring modern advances in
programming language research.

> no compiler OMG!

The compiler and its careful tradeoff between fast compilation and fast
programs is a key characteristic of Go.

> text transformation on the code itself!

Go doesn't have macros. Instead people fall back on code generation, just like
Java.

