Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Apps in Go and Swift

youngdynasty.net

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Writing Apps in Go and Swift

#21

Post by rantanplan »

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…

Was perl ever the language of choice for distributed services or database systems?

Did I miss that part of history?

Re: Writing Apps in Go and Swift

#22

Post by mmjaa »

sephoric wrote: post #8
tannedNerd wrote: post #5

Earlier quoted context omitted.

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.

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.

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

Re: Writing Apps in Go and Swift

#24

Post by mmjaa »

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.

Re: Writing Apps in Go and Swift

#25

Post by woolvalley »

tabs_masterrace wrote: post #11
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…

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.

I don't have a lot of golang experience, but from what I can see here, golang doesn't really either: https://tour.golang.org/concurrency/1

Channels seem like a simple thread safe stream for the most part, which you can get with Rx.

Re: Writing Apps in Go and Swift

#26

Post by axaxs »

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.

Re: Writing Apps in Go and Swift

#28

Post by Groxx »

woolvalley wrote: post #25
tabs_masterrace wrote: post #11

Earlier quoted context omitted.

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.

I don't have a lot of golang experience, but from what I can see here, golang doesn't really either: https://tour.golang.org/concurrency/1 Channels seem like a simple thread safe stream for the most part, which you can get with Rx.

This is correct, golang doesn't give you thread safety for free. Values passed via channels are safe as they're implicitly locked (i.e. it's a blocking threadsafe queue), and there are happens-before semantics for starting a goroutine, otherwise you're on your own (explicit locks / atomics / lock-wrappers like sync.WaitGroup). E.g. variable assignment isn't even atomic.

Re: Writing Apps in Go and Swift

#29

Post by justasitsounds »

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 cannot rightly comprehend the confusion of ideas that led to such a statement.

Re: Writing Apps in Go and Swift

#30

Post by cr0sh »

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.

Perl could've been readable - nothing in the language prevents you from writing readable code. The problem was two-fold, imho:

1) regex was treated like the primary way to do things - even when it wasn't necessarily called for - at the expense of readability (and Perl supported it so well)

2) sysadmins

The two combined together (and possibly the fact that it was the early days of commercial internet service) led to the idea that anything done in Perl was destined to look like "line noise" to actual SWEs.

/just how I saw it...

Post reply on HN