4 ms·

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 y

by gcbw2 8y ago

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.

networkimprov 8y ago
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 8y ago
Was perl ever the language of choice for distributed services or database systems? Did I miss that part of history?
axaxs 8y ago
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 8y ago
  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 8y ago
  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 8y ago
    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 8y ago
I cannot rightly comprehend the confusion of ideas that led to such a statement.
sethammons 8y ago
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 8y ago
  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/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
  - dagw 8y ago
    Go is designed for armies of simple minded developers, And that's a bad thing?
    - lizmat 8y ago
      Simple minded developers are cheap. And in time, easily replaceable by moderately intelligent AI.

by gcbw2 8y ago

networkimprov 8y ago

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 8y ago

Was perl ever the language of choice for distributed services or database systems? Did I miss that part of history?

axaxs 8y ago

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 8y ago
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 8y ago
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 8y ago
  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 8y ago

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

sethammons 8y ago

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 8y ago
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/From-Parallel-to-Concurrent https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
- dagw 8y ago
  Go is designed for armies of simple minded developers, And that's a bad thing?
  - lizmat 8y ago
    Simple minded developers are cheap. And in time, easily replaceable by moderately intelligent AI.