9 ms·

> As a mere average user of computer languages, every time I play around with Go I start wondering how a language like this became so popular. You can pick it

> As a mere average user of computer languages, every time I play around with Go I start wondering how a language like this became so popular. You can pick it up in a weekend. A lower entry bar means more people will try it out. > It feels like it was invented in a universe where Haskell, OCaml, Erlang, Smalltalk, Lisp and so many more languages and research in languages never happened. It was developed in a large enterprise context not in an academic context. I think it shows.

ue_ 10y ago
To be honest, you can probably also pick up Lisp in a weekend, experienced programmer or not. The syntax is also simpler.
- bluejekyll 10y ago
  But all those parentheses! I know it sounds like a lame reason to dislike a language, but I've always found staring at Lisp to be so much more difficult and distracting than C-style syntax.
  - bitwize 10y ago
    Use Emacs and take advantage of its electric indent.
  - nickpsecurity 10y ago
    There was an attempt to deal with that: https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) Also, Julia was syntactic and/or semantic sugar on top of femtolisp. Got converted to it in first pass with LISP's power doing the rest. Here's Stefan Karpinski on that: "So ultimately the reasons for Femtolisp are: 1. Scheme is excellent for writing parsers since trees (aka S-expressions) are its forte. 2. Femtolisp is a small, simple, highly embeddable and remarkably fast Scheme. 3. We control it (and by "we" I mean Jeff) and can fix any bugs we encounter." Yep, No 1 are those godawful parentheses and s-expressions making the job easier. ;)
  - Johnny_Brahms 10y ago
    Did you try coding in it for more than a week? I have found that using a properly indenting editor (Emacs, drracket) the parents just fade away. And then you discover paredit and you start wishing every other language would let you treat your source code like that.
    - bluejekyll 10y ago
      Yes. I was required to use Lisp for intro comp sci in College, followed by all the AI courses in Lisp, then a few jobs. It's just never been a go to language for me.
      - Johnny_Brahms 10y ago
        Sounds fair. Most of the time people say "i don't like the parens" the closest they came to actually using a lisp was JavaScript.
  - pjmlp 10y ago
    printf("Hello world"); Lisp mode, move left parenthesis, remove semicolon (printf "Hello world") Second round if (var == 2) { do_something1 (); } else { do_something2 (); } Lisp mode, move left parenthesis, remove semicolon and curly brackets (if (= var 2) (do_something1) (do_something2) ) On a big source file I am not sure if the amount of parenthesis is bigger than parenthesis , bracket, curly brackets and semicolons counted together.
  - agumonkey 10y ago
    Parens are not syntax to me. Syntax is that ADA thought ' meant string indexing.
  - yomly 10y ago
    From experience of pairing with other people, there are those happy to leave indentation and formatting to their linter/IDE and those who are anal enough to do it all manually. The latter group tend to find lisp not that painful because lisp parens/s-exps are as explicit as you can get, and indentation makes parens almost invisible
  - DonaldFisk 10y ago
    What parentheses?
im_down_w_otp 10y ago
So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, distributed network applications. Which makes Go's rapid popularity as a language for solving the same problem even more peculiar. Especially since Go's surrounding tracing, debugging, and online code swapping facilities are so much worse. I'm sure some component of that is Ericsson's complete lack of interest in evangelism and Erlang Solution's apparent lack of capability to effectively evangelize, but it still seems like Go isn't so much filling a void as it is being better at attracting an ecosystem that delights in reinventing a particular set of wheels. Java was very much the same way for a very long time.
- mahyarm 10y ago
  Golang is simpler java, and that is it's target. It even has the same perf profile as java. Erlang does have a worse perf profile.
  - im_down_w_otp 10y ago
    Yes Erlang does, strictly for execution throughput, but less so for concurrency handling. That is also a solveable problem. It just so happens to be a problem neither Ericsson nor ESL have been interested in solving.
    - bostik 10y ago
      Remember, Erlang was first and foremost developed as a programming language (and runtime) to run Ericsson's phone switches. Session establishment for PSTN can be relatively expensive (much in the way of TLS handshakes), so concurrency and shared-nothing memory model together allowed for real-time streaming to keep on working no matter what else happened. The three main features of a PSTN switch are, after all: 1. Reliable call switching 2. Reliable real-time throughput 3. Reliable billing and accounting data generation We don't think much of throughput these days, when any home office switch has gigabit ports and 40Gb+ backplane. As far as I know, maximising throughput bandwidth was not a primary consideration with Erlang. Reliable real-time streaming is much more about guaranteed latency - and incidentally, optimising between latency and throughput tends to be all about tradeoffs.
lomnakkus 10y ago
[I apologize for the absurdly snarky and ranty post, but I'm going to do it anyway:] > You can pick it up in a weekend. A lower entry bar means more people will try it out. ... and then you get the JavaScript situation where everyone thinks they're an actual programmer at $TEAM_LEAD level of sophistication when it comes to modeling, design, architecture, testing and implementation... but they're really not. It's not their fault per se, it's just that they do not have the necessary experience to realize the areas that they're lacking in. (This is a well-known cognitive bias: More than 50% of people think that they're an above-average driver. There are a precious few who realize that they're not -- they are the exception.) Programming is hard[1] and if there was an instant-humbling device, I'd buy it in spades. [1] Most people focus on the "oh, that's Undefined Behavior" bits of it, but it's not really about that. It's about recognizing the types of mistakes that you make and working to avoid them or creating a system that does, whether that's by testing or proof or whatever. Obviously it still has to be _practical_, but AGAIN... it's about tradeoffs. If you don't care about correctness, I'm pretty sure I can whip up a "solution" to any problem that's fast as hell... and not correct. Summa summarum: I think we need to be thinking a lot more in terms of tradeoffs and not so much in absolutes.
- tagrun 10y ago
  What you described is basically true for any job, and it's more about the culture surrounding the language and particular use case rather than the entry level. I've seen a lot of people in academia writing C++, mostly horrible code. I've seen electrical engineers writing awful assembly code. Because the incentive is mostly to get one task done today. None of these languages have a lower entry bar. JavaScript is pretty much bound to a singular use case (web development) where there is a lot of incentive to get quick money, which attracts all kinds of people. I don't see the status quo you're referring would be much different if the browser scripting language was Haskell or brainfuck.
  - lomnakkus 10y ago
    > What you described is basically true for any job I agree, but there are a lot of jobs where it's actually effectively impossible to distinguish between good vs. bad practitioners of said jobs. I just have this feeling that it should be possible in programming. (Because it's quantifiable... or at least quantizable into "works" or "doesn't work" along any number of axes.) > I've seen a lot of people in academia writing C++, mostly horrible code. I've seen electrical engineers writing awful assembly code. Because the incentive is mostly to get one task done today. None of these languages have a lower entry bar. Same here, only with FORTRAN and C. (This hints that this may be a meta-problem.) > JavaScript is pretty much bound to a singular use case (web development) where there is a lot of incentive to get quick money, which attracts all kinds of people. I don't see the status quo you're referring would be much different if the browser scripting language was Haskell or brainfuck. Well, there is node.js, but really, the problem with JS is... JS. It's just a horrific language semantics-wise (syntax: meh). It was invented and implemented in ~7 days(?) and it really shows. (No blame towards Brendan Eich, he did the best that he could within the deadline and even got a little bit of higher-order programming in there.) It's been improving, but just imagine the burden of improving a language that's already been deployed to 1B+ computers. Not an enviable task. Hopefully WebAssembly will (in time) address these problems and give us a real way to program the front end in $WHATEVER_LANGUAGE_YOU_WANT
agumonkey 10y ago
IIUC Pike spent most of his career in research right ?
- theparanoid 10y ago
  Yes. Pike, Thompson, and Griesemer were at Bell Labs before Google.
- generic_user 10y ago
  A non commercial University research group and commercial Corporation research group can be focused on solving very different problems. I think Pike and the other designers skew more towards corporate research (Bell Labs). And surely the development of GO as well as other Google research projects are intended to win in the market place.
  - jeremy_wiebe 10y ago
    It's probably useful to look at the goals that the designers of go had when they designed the language. All other discussions seem irrelevant about what go has or doesn't have if it wasn't one of the goals. Pike, et al, weren't interested in solving metaphorically "your" programming language problems. They wanted to solve problems they observed at Google and just happened to open source the resulting language. From https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article > The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google
    - agumonkey 10y ago
      IIRC Pike worked on concurrent programming models long before entering Google.

ue_ 10y ago

To be honest, you can probably also pick up Lisp in a weekend, experienced programmer or not. The syntax is also simpler.

bluejekyll 10y ago
But all those parentheses! I know it sounds like a lame reason to dislike a language, but I've always found staring at Lisp to be so much more difficult and distracting than C-style syntax.
- bitwize 10y ago
  Use Emacs and take advantage of its electric indent.
- nickpsecurity 10y ago
  There was an attempt to deal with that: https://en.wikipedia.org/wiki/Dylan_(programming_language) https://en.wikipedia.org/wiki/Dylan_(programming_language) Also, Julia was syntactic and/or semantic sugar on top of femtolisp. Got converted to it in first pass with LISP's power doing the rest. Here's Stefan Karpinski on that: "So ultimately the reasons for Femtolisp are: 1. Scheme is excellent for writing parsers since trees (aka S-expressions) are its forte. 2. Femtolisp is a small, simple, highly embeddable and remarkably fast Scheme. 3. We control it (and by "we" I mean Jeff) and can fix any bugs we encounter." Yep, No 1 are those godawful parentheses and s-expressions making the job easier. ;)
- Johnny_Brahms 10y ago
  Did you try coding in it for more than a week? I have found that using a properly indenting editor (Emacs, drracket) the parents just fade away. And then you discover paredit and you start wishing every other language would let you treat your source code like that.
  - bluejekyll 10y ago
    Yes. I was required to use Lisp for intro comp sci in College, followed by all the AI courses in Lisp, then a few jobs. It's just never been a go to language for me.
    - Johnny_Brahms 10y ago
      Sounds fair. Most of the time people say "i don't like the parens" the closest they came to actually using a lisp was JavaScript.
- pjmlp 10y ago
  printf("Hello world"); Lisp mode, move left parenthesis, remove semicolon (printf "Hello world") Second round if (var == 2) { do_something1 (); } else { do_something2 (); } Lisp mode, move left parenthesis, remove semicolon and curly brackets (if (= var 2) (do_something1) (do_something2) ) On a big source file I am not sure if the amount of parenthesis is bigger than parenthesis , bracket, curly brackets and semicolons counted together.
- agumonkey 10y ago
  Parens are not syntax to me. Syntax is that ADA thought ' meant string indexing.
- yomly 10y ago
  From experience of pairing with other people, there are those happy to leave indentation and formatting to their linter/IDE and those who are anal enough to do it all manually. The latter group tend to find lisp not that painful because lisp parens/s-exps are as explicit as you can get, and indentation makes parens almost invisible
- DonaldFisk 10y ago
  What parentheses?

im_down_w_otp 10y ago

So was Erlang. The language, the runtime, and the standard library were all purpose-built together to solve a real world problem... to build fault-tolerant, distributed network applications. Which makes Go's rapid popularity as a language for solving the same problem even more peculiar. Especially since Go's surrounding tracing, debugging, and online code swapping facilities are so much worse. I'm sure some component of that is Ericsson's complete lack of interest in evangelism and Erlang Solution's apparent lack of capability to effectively evangelize, but it still seems like Go isn't so much filling a void as it is being better at attracting an ecosystem that delights in reinventing a particular set of wheels. Java was very much the same way for a very long time.

mahyarm 10y ago
Golang is simpler java, and that is it's target. It even has the same perf profile as java. Erlang does have a worse perf profile.
- im_down_w_otp 10y ago
  Yes Erlang does, strictly for execution throughput, but less so for concurrency handling. That is also a solveable problem. It just so happens to be a problem neither Ericsson nor ESL have been interested in solving.
  - bostik 10y ago
    Remember, Erlang was first and foremost developed as a programming language (and runtime) to run Ericsson's phone switches. Session establishment for PSTN can be relatively expensive (much in the way of TLS handshakes), so concurrency and shared-nothing memory model together allowed for real-time streaming to keep on working no matter what else happened. The three main features of a PSTN switch are, after all: 1. Reliable call switching 2. Reliable real-time throughput 3. Reliable billing and accounting data generation We don't think much of throughput these days, when any home office switch has gigabit ports and 40Gb+ backplane. As far as I know, maximising throughput bandwidth was not a primary consideration with Erlang. Reliable real-time streaming is much more about guaranteed latency - and incidentally, optimising between latency and throughput tends to be all about tradeoffs.

lomnakkus 10y ago

[I apologize for the absurdly snarky and ranty post, but I'm going to do it anyway:] > You can pick it up in a weekend. A lower entry bar means more people will try it out. ... and then you get the JavaScript situation where everyone thinks they're an actual programmer at $TEAM_LEAD level of sophistication when it comes to modeling, design, architecture, testing and implementation... but they're really not. It's not their fault per se, it's just that they do not have the necessary experience to realize the areas that they're lacking in. (This is a well-known cognitive bias: More than 50% of people think that they're an above-average driver. There are a precious few who realize that they're not -- they are the exception.) Programming is hard[1] and if there was an instant-humbling device, I'd buy it in spades. [1] Most people focus on the "oh, that's Undefined Behavior" bits of it, but it's not really about that. It's about recognizing the types of mistakes that you make and working to avoid them or creating a system that does, whether that's by testing or proof or whatever. Obviously it still has to be _practical_, but AGAIN... it's about tradeoffs. If you don't care about correctness, I'm pretty sure I can whip up a "solution" to any problem that's fast as hell... and not correct. Summa summarum: I think we need to be thinking a lot more in terms of tradeoffs and not so much in absolutes.

tagrun 10y ago
What you described is basically true for any job, and it's more about the culture surrounding the language and particular use case rather than the entry level. I've seen a lot of people in academia writing C++, mostly horrible code. I've seen electrical engineers writing awful assembly code. Because the incentive is mostly to get one task done today. None of these languages have a lower entry bar. JavaScript is pretty much bound to a singular use case (web development) where there is a lot of incentive to get quick money, which attracts all kinds of people. I don't see the status quo you're referring would be much different if the browser scripting language was Haskell or brainfuck.
- lomnakkus 10y ago
  > What you described is basically true for any job I agree, but there are a lot of jobs where it's actually effectively impossible to distinguish between good vs. bad practitioners of said jobs. I just have this feeling that it should be possible in programming. (Because it's quantifiable... or at least quantizable into "works" or "doesn't work" along any number of axes.) > I've seen a lot of people in academia writing C++, mostly horrible code. I've seen electrical engineers writing awful assembly code. Because the incentive is mostly to get one task done today. None of these languages have a lower entry bar. Same here, only with FORTRAN and C. (This hints that this may be a meta-problem.) > JavaScript is pretty much bound to a singular use case (web development) where there is a lot of incentive to get quick money, which attracts all kinds of people. I don't see the status quo you're referring would be much different if the browser scripting language was Haskell or brainfuck. Well, there is node.js, but really, the problem with JS is... JS. It's just a horrific language semantics-wise (syntax: meh). It was invented and implemented in ~7 days(?) and it really shows. (No blame towards Brendan Eich, he did the best that he could within the deadline and even got a little bit of higher-order programming in there.) It's been improving, but just imagine the burden of improving a language that's already been deployed to 1B+ computers. Not an enviable task. Hopefully WebAssembly will (in time) address these problems and give us a real way to program the front end in $WHATEVER_LANGUAGE_YOU_WANT

agumonkey 10y ago

IIUC Pike spent most of his career in research right ?

theparanoid 10y ago
Yes. Pike, Thompson, and Griesemer were at Bell Labs before Google.
generic_user 10y ago
A non commercial University research group and commercial Corporation research group can be focused on solving very different problems. I think Pike and the other designers skew more towards corporate research (Bell Labs). And surely the development of GO as well as other Google research projects are intended to win in the market place.
- jeremy_wiebe 10y ago
  It's probably useful to look at the goals that the designers of go had when they designed the language. All other discussions seem irrelevant about what go has or doesn't have if it wasn't one of the goals. Pike, et al, weren't interested in solving metaphorically "your" programming language problems. They wanted to solve problems they observed at Google and just happened to open source the resulting language. From https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article > The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google
  - agumonkey 10y ago
    IIRC Pike worked on concurrent programming models long before entering Google.