> It's like a C fanatic saying "No useful software can be made using Python", and then asking for a counterexample

At which point you could provide them many, many counterexamples?

I like AI coding assistants as much as the next red-blooded SWE and find them incredibly useful and a genuine productivity booster, but I think the claims of 10/100/1000x productivity boosts are unsupported by evidence AFAICT. And I certainly know I'm not 10x as productive nor do any of my teammates who have embraced AI seem to be 10x more productive.

Ok, so do you have a counterexample?

I don't think this is quite right. Our parents paid for the newspaper but the newspaper was basically the internet of their time. That is where they got sports scores, movie/tv listings, etc. The fact that this was bundled with hard news was mostly a side-effect.

Yes, exactly.

It's not the unproccessable records that are the problem it is the records that are very slow to process (for whatever reason).

I'm unclear what this means. What is the other baggage in this context?

I'm skeptical of this claim. Maybe it's true for some particular brand but that's just an artifact of one particular "premium brand" essentially cashing in its brand equity by reducing quality while (temporarily) being able to command a premium price. But it is easier now than at any other time in my life to purchase high-quality clothing that is built to last for decades. You just have to pay for that quality, which is something a lot of people don't want to do.

Does this article demonstrate that though? I get, and agree, that a lot of people are using "big data" tools for datasets that are way too small to require it. But this article consists of exactly one very simple aggregation query. And even then it takes 16m to run (in the best case). As others have mentioned the long execution time is almost certainly dominated by IO because of limited network bandwidth, but network bandwidth is one of the resources you get more of in a distributed computing environment.

But my bigger issue is just that real analytical queries are often quite a bit more complicated than a simple count by timestamp. As soon as you start adding non-trivial compute to query, or multiple joins (and g*d forbid you have a nested-loop join in there somewhere), or sorting then the single node execution time is going to explode.

But more generally the happy-path/error-path distinction can be a bit murky. From my days writing Java back in the day it was very common to see code where checked exceptions were used as a sort of control flow mechanism, so you end up using the slow path relatively frequently because it was just how you handled certain expected conditions that were arbitrarily designated as "exceptions". The idea behind Result types to me is just that recoverable, expected errors are part of the program's control flow and should be handled through normal code and not some side-channel. Exceptions/panics should be used only for actually exceptional conditions (programming errors which break some expected invariant of the system) and immediately terminate the unit of work that experienced the exception.

You can implement a linked list in Rust the same as you would in C using raw pointers and some unsafe code. In fact there is one in the standard library.