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.

What? https://gcc.godbolt.org/z/EzrWW9ss5

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?

So does Amazon's HTTP API for browser clients. Is Apple going to snuggle up with Amazon and get the Brave browser banned for nuking their ads, trackers, etc?

I know quite a few cloud administrators that are systems programmers. They love to work in languages that they can lean on their compiler and not runtime to find a lot of mistakes.

Experienced programmers, if perf matters to their project, should think about their data structures, memory size, and access patterns. It's not clear why an experienced programmer would think an array defaults to wasting memory on a hash table. Why use an array, if they need lots of values and to delete them at random?

  $ path="/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3"
  $ echo "${path##*/}"
  track1.mp3
  $ basename "${path}"
  track1.mp3
  $ echo "${path}" | awk -F/ '{print $NF}'
  track1.mp3

It's not though. There is nothing inherently negative having to use EGS compared to any other game hub. There is absolutely nothing negative about giving developers more money to make more and/or better games. It's a net negative to take 30% from developers doing the actual work.

Developers being paid to make games sounds great. Why is Epic a bad guy for paying developers?

Agreed. Thinking in arrays is very powerful. Simple.

Say Unix tools returned JSON. What good is that without a schema? Instead of a parser, let's all write schema transforms?

Still prefer:

  @media (prefers-color-scheme: dark) {
    body {
      background: #333;
      filter: invert(.95) hue-rotate(190deg);
    }
  }

What a crock of shit. The failures of the latest Star Wars has nothing to do with a diverse cast. We get it; old, white males (ie. "fans") are pissed. There are good reasons; diversity isn't it.

Note, The Mandalorian is full of diversity and breaks the mold of what old, white males consider as "good" for fathers' parental role or emotion.

I've read it - notice, by the way, that it was also the conclusion of the original benchmark

Unclear. The article's conclusions about spinlocks are completely unfounded by the article's code and benchmarks. You could say the article luckily got it right. That's Linus's ultimate contention; the code is garbage and leads to an undefined conclusion. That what's undefined is the right conclusion is lucky, today, and could be garbage tomorrow.

To me, it is completely reasonable that the original author might have made a mistake like this. After all, when he shared his findings it seemed like he had found something interesting to me! Many people on this very site commented positively on his efforts. There is nothing "garbage" about the code that he wrote, it just doesn't quite do exactly what he thought it did.

It was blogged about, so carries some authority on the topic, and was convincing to readers, but the code did nothing close -- not just "not quite exactly" -- to what it was portrayed to be doing in the benchmarks or article. It is garbage; useless; should be binned. I tried to come up with better adjectives -- "dangerous", "useless", etc -- but they came up short, in subtle ways. Who cares; Linus explains what he means better than the one, concise word.

This is a Linux terminal. I'd guess it see 99.99% ASCII. I think they have bigger fish to fry.

You're absolutely right that Python has also become more and more complex and often not for the best.

As for Python performance, on the contrary, I think there was a large portion of the Python community that did care during my years with it. I think 3.x adoption was hurt a lot by being slower than 2.7.x. I think a lot of the community jumped ship to Golang or similar, for both performance and complexity reasons.

I would absolutely love for C++ to tackle C UB or make incompatible insecure C. Instead, we get stuff like Ranges, time and again. I'm struggling to understand what complexities you are finding it covers that are worth supporting forever, committing gray matter, committing productivity loss, committing debug travesties, &c. Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?

If we can compare C++'s complexity to Python's, then C++ has lost its way. You're saying the same thing as the article and my comment, that C++ is trying to hide complexities, and we're arguing that doing so is instead adding more complexities.

Sure, Python makes it easy to listen on a socket, parse HTTP, and send HTML down -- hiding a lot of complexity. But it's made it impossible to do so very efficiently and scale up. Try and dive into Python's stack for that (Re: 'hold in your brain all the "modern" features'), and you'll get lost in a myriad of CPython (or whatever flavor you choose) generics and indirection that you can't optimize. Startup times matter, because you are all about hiding complexities and went "serverless" and constantly eat cold starts (Re: '"modern" compile times').

I think it's apt to compare "modern" C++ as moving towards something like Python. Not great for a lot of applications of C++ (Re: games, in the article and my focus) or its perceived goals as a better C. That's the point. Many of the C++ additions are being slagged for making a worse C. It's looking nothing like C any longer. It's a giant ball of complexity with dozens of ways of doing the same thing and hoping you learned them all.

This is why I think languages like Rust (or even Go) get a lot of attention. They have a good interop story with C, like C++ has. And if we're going to learn a bunch of non-C looking language grammar, C++ is doing a worse job.

Holding in my brain and using all these "modern" features increases the time I need to think about code, data, and algorithms, and that's usually where most coding spends my time -- thinking.

And "modern" compile times... increasing the time between results and further thinking and writing. Don't forget that; the article doesn't.

And "modern" debugging... well, good luck.