[eventhorizonpl]

"most if not all bugs"

Unfortunatelly logic errors are not caught - this would require some sophisticated AI in compiler. But other problems should be caught.

Of course Rust will not prevent you from placing backdoors and other more sophisticated vulnerabilities in code. Compiler is great, but you still have to think.

[yakubin]

Your comment was dead for some reason. I vouched for it, because I think it's interesting to discuss.

Although obviously no compiler of a Turing-complete language is going to eliminate all logic errors, the user of a language like Rust or Haskell may use the type system to prevent certain classes of logical errors (not just problems with the shape of data, or incorrect memory handling). The way you do it is with Abstract Data Types. One example of such a type in Rust is &str. If you don't use unsafe code, it should preserve the invariant that the slice holds valid UTF-8 data. Containing invalid UTF-8 data would be a logical error, not a memory error or data shape error. Similar things may be achieved in C++ and Java with the use of access-modifiers (public vs private class fields and methods). The idea is well-explained in the famous Parse, don't validate[1] article.

The flipside is that too much of it and code becomes so complicated, it's very hard to work with --- you're falling into a Turing tarpit[2]. It becomes easier to just write simple code without bugs, without using all that type system wizardry. But a judicious use of this pattern, where it's appropriate, may be very beneficial.

[1]: <https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...>

[2]: <https://en.wikipedia.org/wiki/Turing_tarpit>

[wwalexander]

Very true, my phrasing was a bit of hyperbole in retrospect. But the bugs I end up finding at runtime when writing Rust are usually deeper issues with my own reasoning about the higher-level problem, rather than my reasoning about the inscrutable low-level machinations of a memory allocator or garbage collector.