Live data from Hacker News

Writing Apps in Go and Swift

youngdynasty.net

51–60 of 62 posts

Re: Writing Apps in Go and Swift

#51
post #48

Earlier quoted context omitted.

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.

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.

Re: Writing Apps in Go and Swift

#52
post #42

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…

Simple minded is your words, not his (in another talk, I think he refers to these people as regular developers).

The harsh language there is not being "capable of understanding a brilliant language." I'm not aware of what was meant by a brilliant language, but I have to assume that it means research languages. I would not expect fresh grads to build production worthy code in any language, but especially not in a research languages (which typically are relegated to the realm of research because they are not capable of being used by large teams for the making of good software).

I'm in the business of creating value with good software, not ivory tower building that only a smaller proportion of software artisans can build and maintain.

Re: Writing Apps in Go and Swift

#53
post #50
post #43

Earlier quoted context omitted.

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.

The crowing achievements of AI that interact with people are Alexa et al. Alexa can't even tell me what the newest releases are for movies.

When we can talk to an AI and describe something novel and it can interpret that, then I'll start to worry about software development jobs being lost to AI.

Re: Writing Apps in Go and Swift

#54
post #43
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?

Not for companies of Google size wanting to reduce hiring and ongoing project costs.

Re: Writing Apps in Go and Swift

#55
post #50

Earlier quoted context omitted.

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

The crowing achievements of AI that interact with people are Alexa et al. Alexa can't even tell me what the newest releases are for movies. When we can talk to an AI and describe something novel and it can interpret that, then I'll start to worry about software development jobs being lost to AI.

What about being lost to low wages countries, with better wage countries keeping the roles of project management and architecture?

Re: Writing Apps in Go and Swift

#56
post #55

Earlier quoted context omitted.

The crowing achievements of AI that interact with people are Alexa et al. Alexa can't even tell me what the newest releases are for movies. When we can talk to an AI and describe something novel and it can interpret that, then I'll start to worry about software development jobs being lost to AI.

What about being lost to low wages countries, with better wage countries keeping the roles of project management and architecture?

Didn't that scare happen a while ago with everyone worried about India taking all the software jobs? Didn't really happen. Could happen again, sure. I don't think more advanced AI or more simple programming languages will be a large factor in that.

Re: Writing Apps in Go and Swift

#57
post #55

Earlier quoted context omitted.

What about being lost to low wages countries, with better wage countries keeping the roles of project management and architecture?

Didn't that scare happen a while ago with everyone worried about India taking all the software jobs? Didn't really happen. Could happen again, sure. I don't think more advanced AI or more simple programming languages will be a large factor in that.

I can tell you that the trend to offshore is still pretty ongoing in full speed.

Naturally those developers are also entitled to have jobs, the question is how it is actually done in practice.

Sadly a large majority are sweetshops.

Re: Writing Apps in Go and Swift

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

Simple minded is your words, not his (in another talk, I think he refers to these people as regular developers). The harsh language there is not being "capable of understanding a brilliant language." I'm not aware of what was meant by a brilliant language, but I have to assume that it means research languages. I would not expect fresh grads to build production worthy code in any language, but especially not in a rese…

Maybe simple minded is not the right way to put it, however from other talks even modern Java is considered too feature rich for such target group.

Re: Writing Apps in Go and Swift

#59
post #51

Earlier quoted context omitted.

It’s not a memory management system.

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.

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.

Re: Writing Apps in Go and Swift

#60
post #41

Earlier quoted context omitted.

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

Not sure what you mean when you say "common threading issues"; the entire point of the Be design was to force all threads to use message-based communication instead of shared memory for virtually all uses, and mandatory locking otherwise. It's extremely effective.
Post reply on HN