[sethammons]

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.

[pjmlp]

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

[sethammons]

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.

[pjmlp]

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.

[dagw]

Go is designed for armies of simple minded developers,

And that's a bad thing?

[pjmlp]

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

[lizmat]

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

[sethammons]

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.

[pjmlp]

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

[sethammons]

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.