Die ch=k Aussprache hat sich halt irgendwie auch einfach generell so im englischsprachigen Raum etabliert. Das ist ein Laut, den sie in der eigenen Sprache nicht haben. In der Regel können sie auch ein Fauchen nachmachen, aber keine Ahnung, ob das dann mitten in einem Wort zu schwer ist, oder warum sie das konsequent anders aussprechen...

I've kind of standardized on writing it as "Failed to bar when beebbooping, while fadoodling."

Maybe a more concrete example:

Failed to write file when persisting audio, while recording. Caused by: Permission denied.

The while-part is optional, in case you've got a larger context.
Well, so is the rest of it, really. I may just write "Error when beebbooping", if I believe the error from .bar() to describe itself rather well. Error handling is hard. 🫠

But yeah, you kind of have to describe that an error occurred, rather than purely describing what you want to do, because anyhow doesn't prefix it or such.

Ah yeah, I was thinking of the "Caused by" shenanigans, which it prints in addition to the stacktrace.

I mean, you chose to pronounce "ch" as a "k", not us...

Pretty sure that's every political system, unfortunately...

Other useful Debug implementations:

• PathBuf and Path will give you the path with quotes and I believe, it escapes any non-UTF8 characters.
• std::time::Duration will give you reasonably formatted output, like Duration::from_millis(54321) will format as 54.321s, whereas Duration::from_millis(321) will format as 321ms. Not appropriate for every situation, but works pretty well for logging.

*Weiß̈̈rrussich

🙃

Dungeon Lawl Stone Soup 🙃

I think, the problem is that Nvidia has two customer groups. Those that buy their products and those that buy their stock options. Nvidia can produce garbage that completely misses the point of real-world usage, so long as they can convince investors that other investors will join the pyramid scheme. And for that, it just has to look like impressive tech, not actually good or artistically meaningful.

In my experience, the biggest problem is that maintainable code necessarily requires extending/adapting existing structures rather than just slapping a feature onto the side.

And if we're not just talking boilerplate, then this necessarily requires understanding the existing logic, which problems it solves, and how you can mold it to continue to solve those problems, while also solving the new problem.

For that, you can't just review the code afterwards. You have to do the understanding yourself.
And once you have a clear understanding, it's likely that the actual code change is rather trivial. At least more trivial than trying to convey your precise understanding to an LLM/intern/etc..