If you agree that you would be clueless as to what is going wrong and where then that means you don't know how to use existing debugging tools.
And I say 'debugging tools' not 'debugging skills' because using such things are not difficult to use. A lot of people simply don't know they exist, or never got in the habit of using them, or don't know how to be effective with such tools. Often because no one simply told them when learning that, yes, this is important and fundamental.
The better retort to my assertion from someone fond of Rust would be that they have many years and deep fluency with existing debugging tools. It's just that they prefer the workflow of Rust better. Which can be a fair take, and in some problem domains I could see why.
But I've been bringing this up periodically for a while now and the interactions tend to always go this way. Where responses tend to reveal that people fond of Rust generally don't realize the significance of existing debug tooling and never learned how to be fluent with it. Or often don't even know if exists.
OS's today being able to reliably have programs hit a segfault, or some other fault, then halt the program, freeze its state and allow you to inspect every call stack and everything in memory on every thread. That was one of the greatest advents of tooling in programmer historyh. Once upon a time the system could easily just BSOD and reboot for trivial errors.
To see a segfault as now delivering you to the land of being clueless and "Good Luck!" means there is a whole chapter missing on software development and its history.