I feel like "bringing CSP into a modern language" gave Pike's team social permission to launch Golang, but the parent comment is closer to the truth than this summary.
According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
> According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.
You and I disagree in regards to a lot about Golang, but I think you're spot-on here. I've thought for years that it was interesting how yosefk's criticisms of C++ in the "Frequently Questioned Answers" directly correspond to decisions in Golang: "compile times are long" → "use the Plan 9 toolchain", "memory management is difficult and unsafe" → "garbage collection", "templates are a mess" → "no generics", "exceptions interact badly with RAII" → "no traditional exceptions", "header files are a pain" → "use packages and forbid circular dependencies", etc.
Oh, wow. I love the C++ FQA (I'm a C++ refugee, from the nadir of C++, when Alexandrescu's book had just come out and template error messages were still 10 pages long).
I never though to evaluate Golang against it. Great point.
You have to think carefully about how to clean up your object if something throws during its constructor, and throwing an exception in a destructor can lead to your program aborting if that destructor was called as a result of another exception being thrown.
Note that I don't think banning exceptions is really the answer; in particular, the destructor issue is just a specific case of "handling errors during finalization is really hard", and you can't get away from finalization in general. Exceptions really put those issues front and center, though.
Oh, exceptions during construction/destruction, right. I don't think Go addresses that at all. Go's defer is just like a finally block, and panics can happen at any time.
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.
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.)
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].
According to Pike's blog, the real motivating factor for Golang was how forbidding and painful Google's C++ build process was. A lot of Golang makes more sense if you look at it through this lens: above all else, don't be like C++.