Live data from Hacker News

Writing Apps in Go and Swift

youngdynasty.net

11–20 of 62 posts

Re: Writing Apps in Go and Swift

#11

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…

I found adopting a functional reactive programming really works well for multithreaded systems.

GCD is super great and I use it a lot (...if you had to extend AsyncTask recently: my condolences), but it doesn't safeguard you from race conditions, dealing with locks and all that fun stuff.

Re: Writing Apps in Go and Swift

#12
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.

Re: Writing Apps in Go and Swift

#13

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…

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.

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

Re: Writing Apps in Go and Swift

#15

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.

Thanks!

Re: Writing Apps in Go and Swift

#18

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

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.

Re: Writing Apps in Go and Swift

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

Re: Writing Apps in Go and Swift

#20
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…

Comparing Go with Perl is rather odd. Maybe you could tell us why we might regret it more than using Java or C# or Node.js?
Post reply on HN