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

41–50 of 62 posts

Re: Writing Apps in Go and Swift

#41

Post by pjmlp »

Matthias247 wrote: post #37
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 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.

I think BeOS tried to and it did not went well with common threading issues poping up on BeOS apps.

Not sure if Haiku has any improvements regarding it.

Re: Writing Apps in Go and Swift

#42

Post by pjmlp »

sethammons wrote: post #35
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 AnyEven…

Go is designed for armies of simple minded developers, Java 1.0 revisited.

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

-- Rob Pike

From https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...

Re: Writing Apps in Go and Swift

#43

Post by dagw »

pjmlp wrote: post #42
sethammons wrote: post #35

Earlier quoted context omitted.

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

Go is designed for armies of simple minded developers, Java 1.0 revisited. “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them…

Go is designed for armies of simple minded developers,

And that's a bad thing?

Re: Writing Apps in Go and Swift

#44

Post by mmjaa »

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

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

Not really rational.

Re: Writing Apps in Go and Swift

#45

Post by bsaul »

tptacek wrote: post #14

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

Zenly ( http://zen.ly, millions of users, bought by snapchat ) has had an app coded in go and swift for ios ( and go and java for android) for a few years. Judging by the app, and the fact that it’s cross platform i’d say the go part does all the data processing part.

https://m.youtube.com/watch?v=R0oaOohl5jk ( in french but the slides are in english)

Re: Writing Apps in Go and Swift

#46

Post by ptx »

gcbw2 wrote: post #31
axaxs wrote: post #26

Earlier quoted context omitted.

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

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.

Re: Writing Apps in Go and Swift

#47

Post by iainmerrick »

mmjaa wrote: post #44
almostdigital wrote: post #36

Earlier quoted context omitted.

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

Sure. The solution to not wanting to be dependent on Apple's software is .. to use more of Apples software. Not really rational.

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

Re: Writing Apps in Go and Swift

#48

Post by mmjaa »

iainmerrick wrote: post #47
mmjaa wrote: post #44

Earlier quoted context omitted.

Sure. The solution to not wanting to be dependent on Apple's software is .. to use more of Apples software. Not really rational.

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

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

Re: Writing Apps in Go and Swift

#49

Post by iainmerrick »

mmjaa wrote: post #48
iainmerrick wrote: post #47

Earlier quoted context omitted.

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

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

It’s not a memory management system.

Re: Writing Apps in Go and Swift

#50

Post by lizmat »

dagw wrote: post #43
pjmlp wrote: post #42

Earlier quoted context omitted.

Go is designed for armies of simple minded developers, Java 1.0 revisited. “The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them…

Go is designed for armies of simple minded developers, And that's a bad thing?

Simple minded developers are cheap. And in time, easily replaceable by moderately intelligent AI.
Post reply on HN