thezilch

No business has the obligation to keep running what you find useful. If it was that useful, someone else will make it.

If no one is doing it or well, I see no reason to just complain and offer no solution. If there are other solutions and Google is going to hurt or destroy "competition", that's what should be discussed.

But how boring and unhelpful to have someone post it on every product that Google builds.

That's ... not what most people are doing. People send _application_ errors on HTTP 200 response codes, because HTTP response codes are for HTTP and not applications. Most "REST" libraries and webdev get this wrong, building ever more fragile web services.

Why should internal tools not have these things? That kind of argument smells of, internal tools can be slow. No.

Seems we should lift up Dear ImGui -- contribute, donate, feedback (document, gather requirements, etc), etc -- as opposed to suggest we not use it.

Google Domains made Google the equivalent of $0 and would teach them nothing about operating their core businesses.

And his context is what? Selling books and conferences? What has he actually shipped with his ideas?

To me, it's the Clean Code of web services.

Oh boy, a whole pizza!

100%; we do that (see profile).

Why not use APCu?

Classic over-engineered DevOps, adding complexity for complexity sake. When you have a hammer...

Everything you described was 2005.

No one is trying to get it for free. They are trying to get it for [significantly] less than 30%.

If it's so great to use Apple Pay (one click, easy to revoke payment -- sounds great!), why would a customer not use it over browsing to a random page, entering CC details, and worrying if it will be hard to cancel?

I'd guess the convenience is not worth 10%, much less 30%, to most users.

You're not speaking to server authority but lag compensation.

Your "behind cover" example describes best your concern with lag comp. It works both ways. You having lower latency can suffer when attempting to take cover. However, you have the advantage when exiting cover; you will see others first.

It's as fair as it can be. As for feel, it definitely feels fairer than no lag comp.

Of course I want consteval, if a later C++ is available to me, but that doesn't excuse you writing constexpr does absolutely nothing, when it clearly does. It's no surprise your example doesn't fold calls without `-O3` or that one could produce a `constexpr` that doesn't fold to a constant (go ahead and try though :>).

But consteval function is also not a literal replacement constexpr. For example, you can't take a pointer to the former. There's a reason they co-exist and are not useless.

Can you expand on what's fragile or what database you do trust? Do you trust your database or filesystem WAL, journaling, and/or vacuum/compaction?