6 ms·

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 th

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.

sanjeevr 13y ago
Yes. Not to mention incredibly well-tested and battle-worn. The unit test coverage for some of these libraries (like net) is incredible.
haberman 13y ago
I haven't worked with Chromium, but the main C++ code-base at Google is like this for the most part too (especially the core stuff). 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.xml http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...) so that everyone can reap the benefits of this.
- yapcguy 13y ago
  > The C++ culture at Google is amazing 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 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?
  - vinkelhake 13y ago
    You're extrapolating the rewrite of a poorly maintained C++ server to mean something about the overall C++ quality at Google? I fully concur with haberman about the state of C++ at Google.
    - yapcguy 13y ago
      If a simple C++ server is left in such a poor state, it stands to reason, how can there be a culture of C++ excellence? Why wasn't someone assigned to maintain the server? A culture is everybody, not just a few brilliant individuals or teams.
      - thepicard 13y ago
        Because that server was not that important?
        yapcguy 13y ago
        It was the server which allowed customers to download Google software onto their computers. 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?
        jemfinch 13y ago
        You're blowing things way out of proportion because you don't have any idea what you're talking about. 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.
      - magicalist 13y ago
        I'll just go ahead and call a spade a spade and say that this is a stupid line of conversation, and it's pretty clear that you know it. 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.
  - banachtarski 13y ago
    This is why I don't "get" go. If it was supposed to replace C++, why does it not compete with C++ directly? Why were they even using C++ for those projects in the first place?
    - jyap 13y ago
      Initial work on Go started in 2007. Go was announced to the public on November 10, 2009. So Go did not exist when the decision was made in the first place.
    - jjoonathan 13y ago
      Why use C++? Performance, universal familiarity, ability to access low level APIs (libraries, x86, syscalls), abundance of good tooling, manual memory management (+debug tooling), legacy. 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.
    - jeremyjh 13y ago
      I think in the beginning they did think of it as a C++ replacement, but it has been a long time since anyone from the core team has used those terms (system language) to describe it. It is more of an alternative to Java or Python. Possibly the server described should have been written in Java in the first place.
- prodigal_erik 13y ago
  Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem. 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.
  - nly 13y ago
    Avoiding exceptions isn't the worst practice. You still get automatic resource cleanup with RAII when you return from a function with an error code, which is a big win over completely unmanaged C. 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.
  - seabrookmx 13y ago
    > Avoiding exceptions is a worst practice 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 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.
    - mixmastamyk 13y ago
      I found this one compelling: http://nedbatchelder.com/text/exceptions-in-the-rainforest.html http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...
- ExpiredLink 13y ago
  > 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'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++.

sanjeevr 13y ago

Yes. Not to mention incredibly well-tested and battle-worn. The unit test coverage for some of these libraries (like net) is incredible.

haberman 13y ago

I haven't worked with Chromium, but the main C++ code-base at Google is like this for the most part too (especially the core stuff). 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.xml http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...) so that everyone can reap the benefits of this.

yapcguy 13y ago
> The C++ culture at Google is amazing 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 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?
- vinkelhake 13y ago
  You're extrapolating the rewrite of a poorly maintained C++ server to mean something about the overall C++ quality at Google? I fully concur with haberman about the state of C++ at Google.
  - yapcguy 13y ago
    If a simple C++ server is left in such a poor state, it stands to reason, how can there be a culture of C++ excellence? Why wasn't someone assigned to maintain the server? A culture is everybody, not just a few brilliant individuals or teams.
    - thepicard 13y ago
      Because that server was not that important?
      - yapcguy 13y ago
        It was the server which allowed customers to download Google software onto their computers. 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?
        jemfinch 13y ago
        You're blowing things way out of proportion because you don't have any idea what you're talking about. 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.
    - magicalist 13y ago
      I'll just go ahead and call a spade a spade and say that this is a stupid line of conversation, and it's pretty clear that you know it. 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.
- banachtarski 13y ago
  This is why I don't "get" go. If it was supposed to replace C++, why does it not compete with C++ directly? Why were they even using C++ for those projects in the first place?
  - jyap 13y ago
    Initial work on Go started in 2007. Go was announced to the public on November 10, 2009. So Go did not exist when the decision was made in the first place.
  - jjoonathan 13y ago
    Why use C++? Performance, universal familiarity, ability to access low level APIs (libraries, x86, syscalls), abundance of good tooling, manual memory management (+debug tooling), legacy. 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.
  - jeremyjh 13y ago
    I think in the beginning they did think of it as a C++ replacement, but it has been a long time since anyone from the core team has used those terms (system language) to describe it. It is more of an alternative to Java or Python. Possibly the server described should have been written in Java in the first place.
prodigal_erik 13y ago
Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem. 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.
- nly 13y ago
  Avoiding exceptions isn't the worst practice. You still get automatic resource cleanup with RAII when you return from a function with an error code, which is a big win over completely unmanaged C. 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.
- seabrookmx 13y ago
  > Avoiding exceptions is a worst practice 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 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.
  - mixmastamyk 13y ago
    I found this one compelling: http://nedbatchelder.com/text/exceptions-in-the-rainforest.html http://nedbatchelder.com/text/exceptions-in-the-rainforest.h...
ExpiredLink 13y ago
> 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'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++.