pkasting

I was there 06-25, and this matches my recollection. Honestly, it's a very restrained document.

The idea sounds good, even if Epic's recent track record of tools is not inspiring. But the commit messages etc. are very clearly products of vibe-coding. And version control is not the situation where "works 97% of the time" is a good-enough bar.

Passing for now.

XHTML was never all the rage. Your premise is false.

Hard errors up front are great when you control the full content pipeline. It's very rare that that's the case, and was rare even in 2004. As soon as including someone else's broken content in your page prevents users from seeing your content, and that someone else can break the content at any time and you can't control it... few people will want hard errors.

On the contrary, image decoders all run complex processes that try and guess what to do in erroneous cases. I used to maintain Chrome's image decoders, and every single image format has "what the spec says" and then "what people actually do in practice"; you must handle the latter, and it is often very difficult to figure out how to do so. For BMPs, for example, determining whether the author intended 24-bit RGB or 32-bit RGBA sometimes requires decoding the full image and scanning to see whether any pixels' alpha bytes differ from the others, since "all 00" and "all FF" might both be "no alpha".

I also used to work on a production C compiler. Compilers can and do "guess what you meant" in various cases, notably for producing actual human-readable errors or proceeding past various warnings, but if I recall correctly even in more obscure non-error cases.

Hyrum's Law is a real jerk sometimes.

(Tangent: What a pleasure to see your username again; will always think of your readability help fondly!)

This list is missing my personal law, Kasting's Law:

Asking "who wrote this stupid code?" will retroactively travel back in time and cause it to have been you.

Crowing over omitting Arabic numerals in the name of avoiding any kind of cultural influence or bias seems silly when everything is still going to be expressed in decimal.

C++ module implementation is a story with a lot of drama, if you ever want to read up on it.

The short summary, though, is that no toolchain yet has a bulletproof implementation, though everybody at least has enough to let people kick the tires a bit.

Yeah, maintainers would certainly +1 a CL that added a note about the parts of //base to use instead. Trivial oversight.

FWIW, I still think the Google Style Guide banning UDLs entirely is too harsh. I think they should be used sparingly, but there are cases where they make sense.

In Chromium's UI code, we have a lot of APIs that deal with coordinates, which may be in either px or dp. And we have a lot of code that needs to hardcode various constants, e.g. layout values for different dialogs. IMO, it's sane to have UDL support here, e.g. `20_px` (at least if we had separate types to represent these two things, which we don't... don't get me started).

A cursory Chromium code search does not find anything outside third_party/ forcing either signed or unsigned char.

I suspect if I dug into the archives, I'd find a discussion on cxx@ with some comments about how doing this would result in some esoteric risk. If I was still on the Chrome team I'd go looking and see if it made sense to reraise the issue now; I know we had at least one stable branch security bug this caused.

Dunno! My last project there was to add support for one of the TI DSPs, but as I said, that's decades past now.

Anyway, I think there are two takeaways:

1. There probably do exist non-8-bit-byte architectures targeted by compilers that provide support for at-least-somewhat-recent C++ versions

2. Such cases are certainly rare

Where that leaves things, in terms of what the C++ standard should specify, I don't know. IIRC JF Bastien or one of the other Apple folks that's driven things like "twos complement is the only integer representation C++ supports" tried to push for "bytes are 8 bits" and got shot down?

Yes, reading the actual data would still be UB. Hopefully will be fixed in C++29: https://github.com/cplusplus/papers/issues/592

At least in Chromium that wouldn't help us, because we disable strict aliasing (and have to, as there are at least a few core places where we violate it and porting to an alternative looks challenging; some of our core string-handling APIs that presume that wchar_t* and char16_t* are actually interconvertible on Windows, for example, would have to begin memcpying, which rules out certain API shapes and adds a perf cost to the rest).

When I led C++ style/modernization for Chromium, I made this argument frequently: we should prefer the stdlib version of something unless we have reason not to, because incoming engineers will know it, you can find advice on the internet about it, clang-tidy passes will be written for it, and it will receive optimizations and maintenance your team doesn't have to pay for.

There are cases, however, when the migration costs are significant enough that even those benefits aren't really enough. Migrating our date/time stuff to <chrono> seemed like one of those.

It's weird to me, as the former lead maintainer of this page for ten years or so, that this got submitted to both r/c++ and HN on the same day. Like... what's so exciting about it? Was there something on the page that caught someone's eye?

The majority of things Chromium bans would still get banned in green-field use.

Some notable exceptions: we'd have allowed std::shared_ptr<T> and <chrono>. We might also have allowed <thread> and friends.

This bit us in Chromium. We at least discussed forcing the compiler to use unsigned char on all platforms; I don't recall if that actually happened.

Green Hills Software's compiler supports more recent versions of C++ (it uses the EDG frontend) and targets some DSPs.

Back when I worked in the embedded space, chips like ZSP were around that used 16-bit bytes. I am twenty years out of date on that space though.

I don't think that's an accurate representation. There are a few features like that, but the majority of things banned in the Google style guide are banned for safety, clarity, or performance concerns. Usually in such cases Google and/or Chromium have in-house replacements that choose different tradeoffs.

That's different from an inability to refactor.

Both parts of your sentence refer to the Google style guide. This doc isn't the Google style guide. It's the Chromium modern c++ features doc. We don't talk about exceptions or platform-specific stuff (save a note on [[no_unique_address]]) in this doc.

We have base::Callback for when you'd reach for std::function, which provides superior safety.

Sure; you can roll your own, or you can use one of the many other libraries that provide alternatives. There are obvious downsides to the former, and the latter is basically equivalent to using the Abseil ones in terms of practical tradeoffs.

Chromium uses hundreds of other open source libraries. Is there something about Abseil specifically that sticks in your craw?

We have a linter that checks for most of them as a pre-upload hook.

Ex-Google here; there are many people both current and past-Google that feel the same way as the composite coworker in the linked post.

I haven't escaped this mindset myself. I'm convinced there are a small number of places where LLMs make truly effective tools (see: generation of "must be plausible, need not be accurate" data, e.g. concept art or crowd animations in movies), a large number of places where LLMs make apparently-effective tools that have negative long-term consequences (see: anything involving learning a new skill, anything where correctness is critical), and a large number of places where LLMs are simply ineffective from the get-go but will increasingly be rammed down consumers' throats.

Accordingly I tend to be overly skeptical of AI proponents and anything touching AI. It would be nice if I was more rational, but I'm not; I want everyone working on AI and making money from AI to crash and burn hard. (See also: cryptocurrency)

Went there, can definitely recommend

The resource constraints had nothing to do with intentionally not funding "support a competing browser properly", though, and everything to do with just not funding engineering and test work at all except to build Shiny Idea That Got A Promo.

Despite its size, Google does shoestring engineering of most things, which is why so much is deprecated over time -- there's never budget for maintenance.

So I mean in some sense yes, there's valid criticism of Google's "will" here, but that will was largely unaware of Firefox, and the consequences burned Google products and customers just as much or more in the long run. Nightingale looked past individual instances to see a pattern, but didn't continue to scale the pattern up to first-party products as well.

Former Chrome team member here. Nightingale's suspicions were plausible but incorrect. The primary cause of every one of these we looked into over the years (and there were indeed many) was teams not bothering to test against Firefox because its market share was low compared to the cost of testing for it. In many cases teams tried to reduce support burden by simply marking "unsupported" any browser they didn't explicitly test, which was sometimes just Chrome and Safari. We were distressed at this and wrote internal guidance around not doing things like the above, and tried to distribute it and point back to it frequently. Unfortunately Firefox' share continued to go down, engineering teams continued to be resource-constrained, and the problem continued to occur.

Several years ago I glumly opined internally that Firefox had two grim choices: abandon Gecko for Chromium, or give up any hope of being a meaningful player in the market. I am well aware that many folks (especially here) would consider the first of those choices worse than the second. It's moot now, because they chose the second, and Firefox has indeed ceased to be meaningful in the market. They may cease to exist entirely in the next five years.

I am genuinely unhappy about this. I was hired at Google specifically to work on Firefox. I was always, and still remain, a fan of Firefox. But all things pass. Chrome too will cease to exist some day.

Musk did not found SolarCity; that was Peter and Lyndon Rive.

I don't know what "found the Tesla as it exists now" means. Founding and leading are distinct. Musk has been a key leader at Tesla; he was not a founder of it or any merged or acquired company.

I disagree with both the premise and the conclusion.

As far as I can determine, Musk is the sole founder of only two companies -- SpaceX and The Boring Company. The former is clearly valued at >$1B; the latter is not.

He is also the cofounder, with many other cofounders, of a variety of other companies: Zip2, X.com, OpenAI, Neuralink. OpenAI is clearly valued at >$1B; Musk was one of eleven cofounders. My assumption is that your third company is X.com; Musk was one of four cofounders, and the company then merged with Confinity (also multiple cofounders), then took the name PayPal (which had been a Confinity product). PayPal is clearly worth >$1B today. I would find it misleading to say Musk "founded OpenAI and PayPal" given the above, but up to the reader.

Whether this is "more than luck" -- in particular, whether it's actually due to Musk's good leadership -- is far from proven. OpenAI, for example, had $1B in capital pledged at founding, suggesting it was already valued at over $1B at creation time. And the skill sets required to found a later-successful company versus to lead one are distinct. Musk might well be a great founder but bad leader.

(Of course, the obvious intent of my original post was to be a snarky dig at someone I view to be an atrociously terrible leader whose success has been due to a combination of others succeeding despite his influence and simply going all-in with huge amounts of capital every time. If you're not already inclined to view Musk that way, and you believe he's actually a successful businessman who is brilliant if eccentric, then a joke post on HackerNews won't change your mind.)