I kinda think this is the story of "Oh someone wrote a screen editor -- that's the 10th time I heard from other people".
Like, if you write a text editor nowadays, my thoughts would probably NOT be too different, except that 1) I wouldn't speak out, and 2) I'd congratulate you, for real, because this world doesn't give ordinary people good time.
Yeah, my thought when seeing the title of this post was "everyone should build their own text editor". You can start with a couple of hundred lines of code. Not everyone will be happy using their own editor for very long, but it's surprising how little code you can get away with when it's your own and the (many) bugs left in it at any point are the ones that don't annoy you enough for you to spend time on.
My own is absolutely full of bugs and missing features, and probably a real pain to everyone else (to my knowledge only one other person has actually tried to seriously use it - I mostly discourage other users), but that's okay: It has the features I care about, some of which are entirely useless to everyone else. It started because I realised my Emacs config was big enough that I could write an editor in fewer lines.
Yeah, I think it's good to dogfood one's own program. It's just...we are so short of time. We are not the lucky few who could actually pull it off, lol.
Dude has worked on UTF-8, Plan 9, and a very popular language despite its flaws.
I am not accomplished enough to judge him. Nor have I had the pleasure to meet him in person to pass any judgement.
I don’t get this obsession with tone policing, probably borne of corporate tendency towards blandness and inoffensiveness. The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
That's weird, considering I was saying he was wrong about something. That's not tone policing? The breathless hero worship in your comment is ironically a much more insidious form of tone policing.
> The vast majority of interesting people are eccentric and with their unfiled corners, it’s part and parcel of being outstanding in your field.
When you grow up, you'll (hopefully) learn that "being loudly and confidently wrong a lot" and "being unpleasant to work with" are not in fact correlated with any particular metrics of technical success, nor are they part of being an "interesting person". Quite the opposite in fact! (Although TBF it does correlate pretty well with certain measures of "success" and longevity in business and large organizations.)
I don't actually know very much about Rob Pike, but the two issues I've heard his opinions on, they were both wrong and poorly argued. I appreciate you don't think I should be able to say this, but I don't think your tone policing is appropriate for this web site.
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.
> 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
To 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.
I 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.
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.
> 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!
Yea, 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.
I 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.
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.
When 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."
I'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.
Honestly 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
Nothing 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.
Java 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.
When 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.
If 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"?
He'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.
Thanks 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) is not justified? I'm just curious.
C++ 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]."
Thanks for sharing! I'm not really good enough to make the right call, but I get your points. So you would prefer someone in Google to build custom tools or introduce features into the C++ language and compilers to fix those issues, not to create a new language. Either way, this is so above my head :D that I can only listen and learn.
FWIW that is exactly what happened, to some degree.
And I'm not opposed to language change, I just didn't see why they needed to create a new language instead of adopting something the industry was already working on. They could have thrown their weight behind Rust, for example, in the early days.
The specific compromises inside Go seem on the whole quite idiosyncratic and led by Rob Pike's personal biases. And it was sold as "Google's language" when in fact Google wasn't really using it for most of that time (they are in fact adopting it a lot more now)
I think he worked on Sawmill, where he developed a language that looks superficially a bit like Go called Sawzall. Sawzall seems to have been open sourced at some point.
It's got some common syntax similarities like using `a := b` to mean creating a new local variable of inferred type.
They 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."
This 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.
Rust 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.
> Rust development was already in the air a bit at the time that Go made its debut.
Go's debut was in 2009 (1.0 a few years later, but you could have used it not long after its announcement at the end of 2009). Rust's first public release was in 2012. It's very unlikely that early, pre-public release Rust could have had any significant real or hypothetical influence on Go.
Using explicitly checked errors instead of exceptions was a considered design choice and is well explained in the Go literature. It may not be to everyone's taste, but there are reasons for it. One of those reasons is how often very normal flow control is shoehorned into exceptions when they are available.
