thezilch

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.

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

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

Everything you described was 2005.

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.

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.

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.

  $ 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

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

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

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.

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.

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.

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?

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.

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.