3 ms·
Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when th
by vezzy-fnord 11y ago
Not quite. To understand Go, you need to understand the history of the Bell Labs gurus somewhere around the late 9th and 10th editions of Research Unix, when the vestiges of what would become Plan 9 and Inferno began to take shape (the sam editor that would influence acme, the rc shell, mk and the predecessor to 9P [streams] would all originate here - see "Interprocess Communication in the Ninth Edition Unix System" [1]).
Meanwhile, Rob Pike and his contemporaries did language research, particularly related to the semantics of CSP-style concurrency. Syntactically they were all C-like, as the Plan 9/Research Unix community all generally liked it.
Newsqueak was the first and it was a cross between C and with special syntax and semantics for procs (green threads). It was written for GUI workstation environments in mind, the idea being to easily build multi-seat applications. From Newsqueak arose Alef, which refined on it but had manual memory management. Then from Alef came Limbo, the language running on top of the Dis VM that formed the core of the Inferno OS.
Fast forward some years later, Rob Pike and some other Bell Labs vets are at Google. Some event happens which painfully reminds them of mediocrity in computing, that gives them the drive again and they resume right where they left from Limbo.
Go is born.
[1] http://cm.bell-labs.co/who/dmr/ipcpaper.html http://cm.bell-labs.co/who/dmr/ipcpaper.html
- r0naa 11y agoThat was very insightful, thank you for sharing!
- tptacek 11y agoI 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++.
- pcwalton 11y ago> 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.
- tptacek 11y agoOh, 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.
- pron 11y agoWhy do exceptions interact badly with RAII?
- pcwalton 11y agoYou 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.
- pron 11y agoOh, 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.
- pjmlp 11y agoAlthough I would say that is a C++ problem, many other languages with exception support do enjoy more sane models than C++.
- vezzy-fnord 11y agoAccording 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 agoI 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 agoYou 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
- RogerL 11y agoSo, I'm curious. I know how data driven Google is - have they done studies on whether Go met its goals w.r.t C++ development?
- fao_ 11y agoCSP == Continuation Style Passing or?
- vezzy-fnord 11y agoCommunicating Sequential Processes.
- fao_ 11y agoAh, thank you.
- gvickers 11y agoCommunicating sequential processes
- thisrod 11y agoor this: http://usingcsp.com/ http://usingcsp.com/
- 0xdeadbeefbabe 11y agoTo be fair, there is still mediocrity left in computing.
- pjmlp 11y agoYou missed out the Oberon-2 influence on method declaration syntax. :)