[gcbw2]

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.

[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?

[axaxs]

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.

[cr0sh]

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

[gcbw2]

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

[ptx]

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.

[justasitsounds]

I cannot rightly comprehend the confusion of ideas that led to such a statement.

[networkimprov]

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?

[rantanplan]

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

Did I miss that part of history?