4 ms·

According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. Yes, that was the "spark" that m

According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. Yes, that was the "spark" that motivated it, as I hinted it. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++. "Don't be like C++" is pretty much a side effect behind much of the Bell Labs and Research Unix philosophy that values composable byte stream interfaces and liberally using a small number of abstractions. The historical context behind Go that I wrote about is quite undeniable, though. I feel that you're being a tad too contrarian here, but I'd love to know more from your viewpoint.

tptacek 11y ago
I guess my point is pretty simple: Golang could have succeeded at its core task without channels and "select", but could not have succeeded without an ultra-fast toolchain and a carefully designed standard library that nurtured an idiom of composable APIs defined by nothing more complicated than structs. Having native CSP gives Golang a differentiator that it would not so clearly have without it. People can disagree about toolchain quality, and for every person that appreciates a well designed stdlib, there are 3 that appreciate CPAN more. It's harder to disagree with a facility that few mainstream languages provide in any form. So CSP is very important to Golang's identity. It's just not the "why" of Golang (or at least, I don't think it is.)
- vezzy-fnord 11y ago
  You seem to be analyzing this from a more economic approach, whereas I'm leaning to the historical. I think I can incorporate your position, but I feel as though you undermine the role of CSP. You see it as a "differentiator", whereas I see it as a central research interest of Rob Pike's that permeated all his previous languages and naturally had to make it into Go, as well. See this excerpt from the Alef reference manual [1]: chan(Mesg) keyboard, mouse; Mesg m; alt { case m = <-keyboard: /* Process keyboard event */ break; case m = <-mouse: /* Process mouse event */ break; } Now where the toolchain is concerned, again that was adapted from the Plan 9 compiler collection (which even OpenBSD at one point was considering but backed off due to licensing) which makes cross-compilation a surprising breeze. Carefully designed standard library? Plan 9's syscall interface... Composable APIs defined by one key abstraction? Plan 9 syscalls again, though there it was 9P. Speed was a motivator, but again - direct side effect of the "5 Principles of Programming" espoused by Rob Pike [2]. [1] http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref [2] http://users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html

tptacek 11y ago

I guess my point is pretty simple: Golang could have succeeded at its core task without channels and "select", but could not have succeeded without an ultra-fast toolchain and a carefully designed standard library that nurtured an idiom of composable APIs defined by nothing more complicated than structs. Having native CSP gives Golang a differentiator that it would not so clearly have without it. People can disagree about toolchain quality, and for every person that appreciates a well designed stdlib, there are 3 that appreciate CPAN more. It's harder to disagree with a facility that few mainstream languages provide in any form. So CSP is very important to Golang's identity. It's just not the "why" of Golang (or at least, I don't think it is.)

vezzy-fnord 11y ago
You seem to be analyzing this from a more economic approach, whereas I'm leaning to the historical. I think I can incorporate your position, but I feel as though you undermine the role of CSP. You see it as a "differentiator", whereas I see it as a central research interest of Rob Pike's that permeated all his previous languages and naturally had to make it into Go, as well. See this excerpt from the Alef reference manual [1]: chan(Mesg) keyboard, mouse; Mesg m; alt { case m = <-keyboard: /* Process keyboard event */ break; case m = <-mouse: /* Process mouse event */ break; } Now where the toolchain is concerned, again that was adapted from the Plan 9 compiler collection (which even OpenBSD at one point was considering but backed off due to licensing) which makes cross-compilation a surprising breeze. Carefully designed standard library? Plan 9's syscall interface... Composable APIs defined by one key abstraction? Plan 9 syscalls again, though there it was 9P. Speed was a motivator, but again - direct side effect of the "5 Principles of Programming" espoused by Rob Pike [2]. [1] http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref http://doc.cat-v.org/plan_9/2nd_edition/papers/alef/ref [2] http://users.ece.utexas.edu/~adnan/pike.html http://users.ece.utexas.edu/~adnan/pike.html