The same people who wrote the bad old code will be writing the new code. They may hope that it will be better code, but a big ball of mud is a big ball of mud, whatever the language.

Chrome is written by hundreds of people.

It's an absolutely massive codebase.

Yes.

Hundreds of people are writing it even now, adding to that massive codebase. The people writing code in Rust will mostly be drawn from among those same people. They might not be the ones who have been coding the bugs. If not, the new code will, perforce, not be less buggy.

The first sentence is literally not true, and easy to see just from looking at changes in who contributes over time. The number of contributors is not even the same order of magnitude from when it started.

Chrome was released 14 years ago, and they started writing it even earlier than that, so even trivial "passage of time" would tell you it was unlikely to be true - most developers are not working on the same codebase or even at the same company, they did 14 years ago. This was much more common in tech decades ago , but not anymore, and not been true for a long time.

So even if it was "bad old code" (which, i'll explain, is also nonsense), the same people aren't writing it.

As for "bad old code" - Chrome was faster, safer, less janky, etc, than its contemporaries for many many years since inception.

So when you say "Coding in Google-dialect C++ was a spectacularly bad choice, evident even then", it just makes you look silly - it clearly was not. If it was such a bad choice, evident even then, the former would not have happened.

Overall - to look at clear success and basically say "they totally fucked everything up, and i wouldn't have done it, because i know better", is pretty arrogant. To then think that if there are bad design decisions, the main bad ones from decades ago are the programming language, is honestly the most hilariously arrogant thing i've read on HN in a while.

So congrats?

The article is an extended admission of series of bad decisions leading to problems so bad they feel they need to switch programming language to try to patch up after. If there were not fundamental problems they have failed to address, none of this would even be under discussion.

It is face-saving to blame the programming language, but we should not be fooled. A good craftsman does not blame the tool.

Pretty much nonsense, really. Given the herculean effort Google has put into Chromium to deal with these sorts of problems and the massive investment they've made in C++ it should not be taken lightly at all that they're choosing any other language for a project that has been using it for decades.

> Canonically, the good craftsman does not blame the tool.

Yeah that's so true, that's why we build our sky scrapers by bashing rocks into wood and walling it up with dried feces and dirt, right?

If you don't understand the expression, it would be better to make that effort than to post a foolish misunderstanding.

Well my first pass at a post was to tell you that you sound like a dumbass, so be glad you got what you got.

You have already presented your credentials, thank you.

I am not a fan of the Google dialect of C++. That said, there is no dialect of C++ that would solve the issues they are running into and will continue running into if they use C++. Every major user of C++ regardless of organization or style guidelines has the exact same concerns with the language.

I never get memory usage errors in my C++ code. Many others, likewise.

It is probably true that Google staff, with their existing education and background, cannot achieve this, but other organizations do.

There is of course no possibility of Google recoding all of Chromium in modern C++ or Rust, so they will live with the bugs they have already coded. A new browser, such as Ladybird, could avoid Google's failings.