Writing Apps in Go and Swift • Hacker News Board

Re: Writing Apps in Go and Swift

#31

Post by gcbw2 » Wed, Jan 30, 2019, 12:06 AM UTC

axaxs wrote: post #26

gcbw2 wrote: post #19

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…

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.

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 :)

Re: Writing Apps in Go and Swift

#32

Post by pornel » Wed, Jan 30, 2019, 12:11 AM UTC

iainmerrick wrote: post #3

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 an…

GCD is fantastic and way better than everything on macOS before it, but it's still not a silver bullet (neither is Go).

Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue. If you add KVO/bindings into the mix, it needs an extraordinary level of paranoia^Wdilligence.

Re: Writing Apps in Go and Swift

#33

Post by saagarjha » Wed, Jan 30, 2019, 12:33 AM UTC

pornel wrote: post #32

iainmerrick wrote: post #3

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 an…

GCD is fantastic and way better than everything on macOS before it, but it's still not a silver bullet (neither is Go). Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue. If you add KVO/bindings into the mix, it needs an extraordinary level of paranoia^Wdilligence.

> Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue.

This basically just boils down to "don't touch the UI off the main thread". There are some exceptions with CoreAnimation, but other than that the main thread checker will yell at you if you do something wrong.

Re: Writing Apps in Go and Swift

#34

Post by saagarjha » Wed, Jan 30, 2019, 12:35 AM UTC

bunnycorn wrote: post #23

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.

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.

Re: Writing Apps in Go and Swift

#35

Post by sethammons » Wed, Jan 30, 2019, 12:38 AM UTC

gcbw2 wrote: post #19

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…

I'm in the midst of a giant Perl rewrite to Go. I see Perl as glue code, but as soon as you want a "real app" (for various definitions thereof), Perl will bite you. Go is designed for large teams and networked services with concurrency as a first class citizen.

In our Perl code base, we have had so many issues with auto-vivification, lack of argument tracing (just pass around @_ everywhere!), callback hell in AnyEvent for concurrency, and more. Maybe if you use Moose everywhere, you can get some form of sanity, but I doubt it. Engineers I have full respect for have scratched their heads trying to initially dive into this perl. What I can grant however is that it is able to do a lot of work (given enough machines!).

For the Go version, I know exact method signatures and variable types. Concurrency if first class. And just about anyone can read the code and figure out what is going on. We've onboarded new grads who can help put solid features into this already large Go codebase quickly. We are seeing 20x optimization in throughput over one code base from Perl (it requires a lot of waiting on remote servers we don't control), and 100x in another.

I can't imagine regretting the choice to write in Go for networked services running in the backend.

Re: Writing Apps in Go and Swift

#36

Post by almostdigital » Wed, Jan 30, 2019, 1:32 AM UTC

mmjaa wrote: post #24

coldcode wrote: post #4

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.

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.

https://github.com/apple/swift-corelibs-libdispatch

Re: Writing Apps in Go and Swift

#37

Post by Matthias247 » Wed, Jan 30, 2019, 1:56 AM UTC

pornel wrote: post #32

iainmerrick wrote: post #3

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 an…

GCD is fantastic and way better than everything on macOS before it, but it's still not a silver bullet (neither is Go). Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue. If you add KVO/bindings into the mix, it needs an extraordinary level of paranoia^Wdilligence.

> Cocoa is incredibly fragile about the main thread

That basically applies to all UI framework. At least I'm not aware about one which provides good support for accessing it from another thread.

There is obviously a reason for it, which is that UI frameworks are incredibly stateful, and trying to manipulate lots of state from multiple threads at once rarely works out well.

Re: Writing Apps in Go and Swift

#38

Post by armadsen » Wed, Jan 30, 2019, 2:00 AM UTC

almostdigital wrote: post #36

mmjaa wrote: post #24

Earlier quoted context omitted.

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.

https://github.com/apple/swift-corelibs-libdispatch

Yeah. Worth noting too that libdispatch has been open source since it was released 10 years ago. I compiled and used it on Linux before Swift was out.

Re: Writing Apps in Go and Swift

#39

Post by alexashka » Wed, Jan 30, 2019, 2:36 AM UTC

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.

Re: Writing Apps in Go and Swift

#40

Post by favorited » Wed, Jan 30, 2019, 3:41 AM UTC

saagarjha wrote: post #33

pornel wrote: post #32

Earlier quoted context omitted.

GCD is fantastic and way better than everything on macOS before it, but it's still not a silver bullet (neither is Go). Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue. If you add KVO/bindings into the mix, it needs an extraordinary level of paranoia^Wdilligence.

> Cocoa is incredibly fragile about the main thread, so you need to be super careful what runs in what queue. This basically just boils down to "don't touch the UI off the main thread". There are some exceptions with CoreAnimation, but other than that the main thread checker will yell at you if you do something wrong.

The main thread checker is a godsend. Enabling it + TSAN + Core Data concurrency assertions have reduced the threading bugs my team deals with to almost 0.

Anywhere we're doing something specific, we make liberal use of `dispatchPrecondition(condition: .onQueue(mySerialQueue))` or `assert(Thread.isMainThread)`.

Even in places where we are doing multithreaded UI rendering (mostly CATiledLayer), it's become a non-issue. It's a night-and-day difference compared to 5+ years ago.