As someone not at Google, but who's re-used multiple parts of Chromium (as described in the article), the code (especially the stuff under base/) is possibly the best documented large-scale, open-source C++ codebase I've seen.
The C++ culture at Google is amazing, and proof that large-scale C++ can actually be really nice if you stay within best practices. It takes a lot of effort and experience from a lot of knowledgeable people to craft these practices, but thankfully Google publishes its C++ style guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...) so that everyone can reap the benefits of this.
Yet the C++ code powering downloads was pretty bad and poorly maintained, written, replaced with Go.
http://talks.golang.org/2013/oscon-dl.slide#10
For sure there are great C++ programmers at Google, but across the company as a whole?
I fully concur with haberman about the state of C++ at Google.
If your download server was slow and randomly disconnecting transfers for no good reason, resulting in potential customers giving up, wouldn't it be important?
It was a server involved in a fraction of Google's downloads comprising an even smaller fraction of Google's total egress. It took URLs of one form and redirected them to URLs of another form, where other C++ servers written by a staffed team (mine) actually redirected them to the actual C++ servers (again, deployed and maintained by my team) which deliver the downloads.
haberman wasn't talking about the state of Google's C++ codebase in 2005; he was talking about the state of Google's C++ codebase in 2014. This server was written years ago, using libraries that were years old at the time it was written. It wasn't maintained, and no team was responsible for it. The core libraries on which it was based were replaced by the libraries haberman lauded.
The only reason you can even try to use this server as an example is because you have no clue what you're talking about.
Not only did the person you originally responded to even qualify with a "for the most part" -- thus allowing for the existence of bad code in said C++ culture -- every significant codebase in the verse has a neglected corner or three. Moreover, one man's "globally crappy" code is another man's halfway-decent code. We have no way of identifying how bad the code was, just that it was stalling a whole CPU without doing anything while I/O bound.
Finally, your whole point is ridiculous, because the slide deck you link is about finding a part of the codebase that has accumulated extreme cruft and replacing it with a new, clean implementation, which is exactly how you maintain a healthy codebase.
Go troll a new thread or find an actual point.
Go was announced to the public on November 10, 2009.
So Go did not exist when the decision was made in the first place.
Why not directly compete with C++? The performance and compatibility/"close to the metal" requirements are separate. Much of C++'s complexity comes from the latter. It makes sense to create a solution for applications that require one but not the other.
If the profession ever wants to produce anything reliable in C++, one of the first things that needs to happen is to start treating all unsafe legacy code like toxic waste, marking it clearly, handling it carefully in isolation, and disposing of it with prejudice as soon as possible. I don't ever expect to see this, which is partly why I switched to languages that try to handle failures and mistakes gracefully.
I generally agree though, error paths are the last area I want to expose myself to flaky manual propagation and the 'well, I think I handled/freed everything' discipline. The regimental 'goto cleanup' type code you see in the kernel is not something I want in my projects.
You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is best practice.
I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I:
http://www.joelonsoftware.com/items/2003/10/13.html
Error handling is essential, but exceptions are far from a perfect solution. The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions. One just needs to be vigilant when handling errors.
http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...
Also I don't personally agree with the idea that exceptions communicate errors better. In his examples, he's taking an error code and converting it to an exception. Obviously all the information needed about that error is conveyed by the code, otherwise this approach wouldn't work.
Wrangling of this information shouldn't be happening in the middle of application logic. The return code should be acknowledged by the recipient so the necessary cleanup can be performed, then it should be piped to a central class in charge of printing/logging errors. Sprinkling these error code conversions all over the place makes things messy and hard to maintain.
Edit: clarity.
The amount of error-unwinding goto spaghetti, ERR_CAST/IS_ERR/PTR_ERR/... and all the bugs coming from it is not "just fine".
Passing -ENOMEM 5 layers upwards stops being fun very quickly.
Though I somewhat agree with you, in that C++ exceptions definitely are not the error handling method, such examples don't really mean nor prove much for this subject. Especially since the kernel isn't even written in C++ and is a pretty special beast compared to, say, a typical desktop or app. So now browse to https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P
Taking software seriously involves ensuring every failure is handled. Dropping them on the floor is almost never the right thing, which makes it crazy to have that quietly happen by default. Joel points out code without exceptions becomes very verbose and littered with local handling, but overlooks that it's so painful that most developers can't be relied on to actually do it.
I'm in no way saying its perfect though.
> Taking software seriously involves ensuring every failure is handled
> it's so painful that most developers can't be relied on to actually do it
I agree with both of those points (as any decent developer would), but I don't believe exceptions remedy either of those issues.
The architects behind Go, truely some of the best minds in computer science, did not include exceptions because of this.
The tl;dr is that errors get dropped a lot with return codes. It's so easy to do, even in battle-tested, critical code like the Linux kernel.
This has already been done, so you are obviously wrong.
Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.
Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.
Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.
What's great about this is I might call a method that simply concatenates two strings, that is all it does, and I know this won't fail(OOM can always happen, but good luck recovering from that), so I don't return a status. I can call this method assuming no failure and no boiler plate is needed. With exceptions, there's always that possibility that an exception can be thrown. What if I call this method from code that needs to close resources? Great, now I absolutely must have RAII for cleanup, which is more complicated than just doing close(x). Also, what are you going to do when using 3rd party code with its own base exception class? Now, at the upper layers of your code, you have to have a handler for each base class. Without exceptions, someone might have their own status object they return, and I'll need to translate that, else my code won't compile. Your code will compile even though you might not handle that 3 party base exception class.
Of course, most times code just propagates the error up so that adds to boiler plate without exceptions.
I think the talk of using exceptions vs returning a status is a red herring. They have their positives and negatives, and we can argue this until the cows come home. The most important thing is to use a set of well defined success/error codes, whether this comes from exceptions or a returned status isn't really important. I've seen codebase with C++ exceptions working just fine, and I've seen c++ code with no exceptions, and it worked well. The commonality between these two cases is .... well defined error codes.
It's real-world C++, not 'Modern' or Boost- or 0x-C++ (not even C++98). There is a huge gap between C++ development in the trenches and what is published on the internet about C++.