> The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.

Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs.

Even C++ would be a safer choice because of RAII.

When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.

Did it find any real potential issue, optimization/simplification opportunities, or sparked any thought-provoking discussion within your organization?

Or was it purely a net negative experience?

The grandma that would have phoned her nephew to fix the phone will still do the same thing now. She will not have magically switched to querying LLMs after a lifetime of technological illiteracy.

The tech-savvy person that uses AI today would have been more than capable than figuring out how to fix their router by using Google even without prior networking skills/experience 5-10 years ago.

Using AI to solve these problems is a novelty for a specific subset of the population. And the topic does matter.

Even the somewhat tech-illiterate mom would have been able to Google a recipe 10 years ago, or watch an Instagram reel 5 years ago. They were surely not going to call their friends to ask instructions on how to make an apple pie.

Pretending this is an AI novelty is indeed disingeneous.

Pretending it's an AI novelty is... disingenuous.

I wouldn't have called a friend for a meal plan or to figure out a hiking path 10 years ago, I would have used a search engine.

If I want to talk to a friend, I don't need an excuse to do so. And I'm not going to waste their time by asking something I can easily figure out on my own, today with AI, years ago with Google, and prior to that with printed material.

The anti-AI craze is just as bad as the "AI will solve everything" crowd.

I faced a similar issue myself when implementing a chunked vector a la `std::deque`, but opted for callback-based internal iteration, i.e.

    void ChunkedVector::forEach(auto&& f)
    {
        for (auto& chunk : chunks)
            for (auto& item : chunk) 
                if (f(item) == ControlFlow::Break)
                    return;
    }

    enum class [[nodiscard]] ControlFlow : bool
    {
        Continue,
        Break
    };

It's sometimes inferior in terms of ergonomics, and cannot express more complicated algorithms or iteration patterns (e.g. partial range, going backwards), but so far it has served me well.

Just something to consider if implementation simplicity is the priority and there's no need for a very generic suite of algorithms.

This is my `sf::base::Optional` template class, a lightweight replacement for `std::optional` with same semantics: https://github.com/vittorioromeo/VRSFML/blob/master/include/...

This is what ClangBuildAnalyzer reports:

  **** Template sets that took longest to instantiate:
     833 ms: sf::base::Optional<$> (911 times, avg 0 ms)

I'm sure I can optimize it even further if I wanted to.

---

Now to refute your other incorrect claims:

> The point of templates is generic programming, reusable components.

That's ONE use case. A more general use case is just reducing code repetition in a type-safe manner, which is extremely useful even within the same translation unit. Another use case is metaprogramming. And I'm sure I can come up with more. Templates are a versatile tool.

> And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times.

...well, yeah? Of course you have to put in effort to reduce compile times. That doesn't undermine my point at all.

C++ templates are not slow to compile.

My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time.

Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation.

Most people still think that templates have to go in header files, which is also just plainly false.

I'm sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days. So where do you draw the line? Regardless, it matters.