4 ms·
He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to add
by dist-epoch 2mo ago
He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem.
- atherton94027 2mo agoHonestly could you blame him for not liking Java in 2007? Between the many layers of abstractions the frameworks used, the exceptions and the sluggishness to compile it was not a compelling stack
- speed_spread 2mo agoNothing would have prevented building a nice, lightweight system in Java in 2007 had one thrown away the conventions that had infested it at that point. Java's problem never was the language which has been as serviceable as any other since the JDK1.4 days. It is straightforward to compile (no metaprogramming, type erased generics), linking is delayed to runtime and dependencies are all precompiled to bytecode which _should_ make for very fast builds. The problems came from the multitude of Internet-bubble era tool vendors which overcomplicated everything in order to sell high priced "corporate-level" solutions and imposed that certain coding style. Java is still known for this today because it appears in so many vintage codebases and is still being applied by coders who never revised their practices from 22 years ago. My theory is that Rob Pike was jealous of Java because it has succeeded with a model similar to his own Inferno (bytecode, C syntax) and this aligned with Google's ask of developing something that would be outside of Sun's lawyers reach.
- cmrdporcupine 2mo agoJava and the JVM does show its age specifically in one era, and that is its OO-dogmatism which it inherited from the 1990s OO wave (i-was-there-gandalf.gif). Even the opcode set in the VM reflects this everything-an-object mentality. While it's been made to work, the JVM itself isn't the greatest VM for hosting other non-Java-shaped languages because of this.
- genxy 2mo agoWhen the Java people showed up to Python, they brought a bunch of that FrameworkFactoryItis with them, it was looking pretty bleak for a couple years. The culture that springs up around a language is as important as the language itself, even more so. It spreads to the libraries, and in turn the applications.
- f3408fh 2mo agoBullshit. He describes the actual reasons here: https://go.dev/talks/2012/splash.article#TOC_4 https://go.dev/talks/2012/splash.article#TOC_4. And anyway, since when is not liking something a bad reason to try your hand at creating a better thing?
- tripledry 2mo agoThey are probably referring to what Rob said in a presentation. "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."
- f3408fh 2mo agoAh, well, I take it back then. Sorry dist-epoch!
- cestith 2mo agoThis sounds like he's discounting Lisp, Scheme, OCaml, and Haskell in favor of something that's more of a safer, fresher take on the C language for his target group. The real competition for a language like Go these days are Rust, Zig, maybe D or Swift. Python, Fortran, JS, TypeScript, PHP, Julia, and such are mostly used in other niches. Common Lisp, Scheme, Haskell, OCaml, Objective Pascal, Ada, and several more are capable languages but don't benefit as much from the network effects of C-family syntax.
- cmrdporcupine 2mo agoRust development was already in the air a bit at the time that Go made its debut. And in a shape at the time that was arguably more Go-shaped than what it became (did not have borrow checker yet, and had a managed runtime and GC option as well I think). I personally think hubris led to Pike not working with others in the industry and Go bears the stamps of some very unfortunate idiosyncratic decisions as a result. The error handling in particular is awful. Refusal to admit parameterized types (until forced to, later) another. I like to imagine an alternate reality where Google and Mozilla had birthed something together halfway between Go and Rust. I think the world really still needs something like this for server development; parametrized types, ML-influenced type system, proper strictly typed error handling and pattern machine like Rust / ML; native code production like both; but with GC and fast compilation and a good powerful standard library like Go. Closest to this out there might be OCaml, I dunno. Maybe Swift.
- ferguess_k 2mo agoIf average Google programmers are too stupid to program in C++, what kind of qualities are needed to get good at programming in C++? Like 140+ IQ? Or one needs to really sit down, think through, slow down, which is against the "velocity"?
- cmrdporcupine 2mo agoHe's also wrong; the average Google programmer was more than capable of producing good C++ and Google's C++ tooling and standardization was excellent. Source: worked there. That's not to say that C++ is a good or appropriate language or that the codebase wouldn't have been better served by another language. But "stupidity" was never the problem. And Go is not the "another language" I think fits the bill (and in fact was barely used at Google when I was there) I don't even know what actual production systems Pike ever worked on, before being given carte blanche to go off and make a new programming language to supposedly fit that niche? In any case, Go is an insulting language to work in, which is not surprising since its origin story seems to involve insults.
- ferguess_k 2mo agoThanks for sharing. Do you mind to share a bit more about your observation and experience with C++ in Google? I'm just curious what kind of guidelines and practices produce better C++ code, because I have used C++ in my side projects, but I found it difficult to command -- it was always like handling a lot of dishes without breaking any -- that's why I talked about IQ. And when you said "before being given carte blanche to go off and make a new programming language to supposedly fit that niche?", did you mean that (https://go.dev/talks/2012/splash.article#TOC_4 https://go.dev/talks/2012/splash.article#TOC_4) is not justified? I'm just curious.
- cmrdporcupine 2mo agoC++ at Google is highly restricted to fit to a very normative style guide. And there was strong leadership while I was there to help define what sane defaults might look like (Titus Winters FTW). And then there was a lot of efforts into build system and static analysis tools to help enforce that. And then on top of that a very strong foundational set of libraries on which things were built that were also built quite well. Again, I have real problems with C++. And always have. These days I'm a Rust developer. (Which I have my own criticisms of...) But two things: Google developers are actually better than average, which is why Pike's comment seems so offensive in context. And C++ is the tool that Google already had, so sensible engineering is at least partially investing in incrementally improvement, not rewrite the world. As for the article you linked to: I don't disagree with all of the conclusions in there. But I disagree with the hubris of "we need a new language" for an organization at the scale at which Google operate(d). And also I think it smells suspiciously like "I have a hammer and need a nail"; by which I mean some smart engineer who (rightfully and properly) enjoys programming language design (or some other neato CS thing) ... and is annoyed and bored by the actually-existing boring protobuf shuttling work at Google ... gets carte blanche to build A New Hammer [which usually looks almost exactly like the things they personally have built before] and then goes hunting for nails for it. Which is honestly I think backwards to a healthy engineering culture, and is also a phenomenon I saw too many times at Google (I think Dart and Flutter and Fuchsia had similar cultural problems). The job of a software engineer is to solve the organization's problems. I don't rule out that neat new tools might be needed sometimes to do that. I sure as hell would love to build those tools. But I want to put the problem first, not the tool. I also disagree strongly with many of the fundamental design choices that went into Go from day one. Most odiously: Its error handling, its naming scheme (touched on in that article), and its lack of parametrized types (since fixed). Other things (packaging, etc) in that document I strongly agree with but they're relatively uncontroversial. Also, when I first looked at Go I was like "ok, you say you built a language specifically for Google's needs but it just looks like you reheated Limbo [his previous language]."
- pjmlp 2mo agoHe also doesn't like C++, that was the main reason, note that Plan 9 and Inferno contrary to UNIX, also don't do C++.
- andsoitis 2mo ago> He created Go because he believed that the average Google programmer is too stupid to program in C++, and he didn't like Java, the other language created to address this problem. It is more nuanced than that. Created Go because: a) C++ deemed excessively and unnecessarily complex, overloaded with features, increasingly difficult to manage b) Very slow compilation times c) Wanted a language with built-in concurrency (neither C++ nor Java qualified) d) Enable fresh-out-of-university team mates to be effective
- eloisant 2mo agoTo be fair Java was created in a world where you'd run hundreds on services on a single server, run them in application server with a persistent JVM running. Now with containers, running Java apps in containers isn't great because of that JVM layer. Memory management, JVM boot time, etc. There are many things I dislike in Go as a langage but create a high level language that compiles to native makes sense in the cloud hosting/containers world.
- cmrdporcupine 2mo agoI mean, I don't think there's nothing intrinsic to the JVM design on paper that requires this memory model. Just to the specific extant JVM implementations out there. I haven't kept in touch with what has been happening in the Java world since I stopped working in it (uh, probbly 15 years ago) but you'd think someone would have come along at this point and created a lighter weight JVM solution that starts faster and manages memory in a more container-friendly way.
- joas_coder 1mo ago> Now with containers, running Java apps in containers isn't great because of that JVM layer. Funny, Ironwood (https://github.com/ironwood-lang/ironwood https://github.com/ironwood-lang/ironwood) explores exactly this space: familiar Java programming without JVM startup, warmup, or GC.
- sherburt3 2mo agoKind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things.
- mjr00 2mo ago> Kind of a bummer that 95% of software engineering is dedicated to creating a padded cell to make sure no one makes a whoopsie instead of doing creative and interesting things. s/software engineering/running a business. I'd much prefer that the people building the bridges and planes I use, or the staff at the hospital I visit, have procedures in place to prevent them from "making a whoopsie" than the space to be creative or interesting. Even if they enjoy their job less. The good news with software engineering is that unlike building a plane or running a hospital, nobody is stopping you from making your own projects and being creative and interesting as you want!
- ryandrake 2mo agoYea, it's too bad that "making whoopsies" has become such a common occurrence, treated so casually, in what is made out to be a serious engineering discipline.
- cmrdporcupine 2mo agoI mean, all engineering disciplines seemingly build in for margin of error / tolerances. e.g. Bridge, etc. are often overbuilt in case of faults in materials or expected circumstances. I do agree our profession grapples with complexity in bad ways though.
- transdev12 2mo agoStrongly disagree with your premise. Programming languages are what you build creative and interesting things from, building in safety into your tools is a good thing. I wouldn’t want a nail gun that shoots in the wrong direction when you apply the incorrect amount of pressure. Software engineering over indexes on an obsession with the tools themselves over the things you make with them.
- chillpenguin 2mo agoWhen he said the average programmer is too stupid to program in a brilliant language, I don't think he was referring to C++. I think he was referring to non-mainstream languages that require totally different ways of thinking (there are many, and I don't know which ones he had in mind, so I won't list any examples). So he designed Go to be very familiar to average programmers, instead of embracing more powerful ideas (which average programmers would have a hard time with). That was my understanding at least. If you have evidence that he was referring to C++, I'd love to see it! I'm open to being wrong, and it would totally change how I interpreted the situation if he was indeed referring to C++ as a brilliant language. For those not familiar, here is the quote by Pike that is being referred to, where he infamously implied most programmers are too stupid to use a good language: "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."
- dist-epoch 2mo agoI'm not sure what he meant by "brilliant language", but he was working in C++ and was frustrated with it when he decided to create Go. > Back around September 2007, I was doing some minor but central work on an enormous Google C++ program > I actually tried and failed to find a way to bring the ideas to C++ > Some were very subtle and hard to understand, like rvalue references, while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals. https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...