For a hobbyist, that’s perfectly reasonable. For a professional, it’s incumbent upon them to take care not to create situations that result in failure. Part of my job as a team leader, and later as a manager, was to ensure everyone on the team was qualified and took appropriate measures to make sure their code was technically correct and without security issues. We also performed code reviews to catch errors the original developer may have missed, and our test teams also added another layer of verification on top of that.
It’s my opinion that languages like rust are band aids on the real problem–programmer carelessness and incompetence. Many of the common issues (stack overflows, memory leaks) are so well known and understood that there’s no excuse for anyone to make them anymore.
For new development, rust does make sense, as long as the team is adequately trained in its use. Making an experienced team use a language they just learned has its pitfalls too, as people tend to make more mistakes with tools they don’t have much experience with.
Taking a large existing codebase written in, for example, C, and recoding it in rust is an exercise in futility. It’s almost guaranteed that new bugs will be introduced into the new codebase that were painstakingly found and fixed in the old codebase over the years. I’ve seen this happen time and time again during my time in the industry, and it was never pretty. The only reason to completely rewrite an existing codebase is if that codebase is hopelessly buggy and poorly organized. Doing it for nearly any other reason is a waste of time and money.