[xxpor]

Notably, no language will ever be able to catch pure logic errors by itself. The computer can't and shouldn't try to divine what you meant. It'll only do what it's told.

Now, there are certainly advantages different languages have in ease of writing tests and things like that. There's also formal verification. But unlike memory errors, it's impossible to know if you told the computer to do something you didn't intend.

[roca]

> Notably, no language will ever be able to catch pure logic errors by itself.

It's true you'll never be able to catch all logic errors automatically, partly because you need full correctness specifications for that.

But languages like Rust with powerful static type systems can catch lots more important logic errors than C, or C++ --- e.g. using typestate (catches bugs with operations on values in incorrect states), affine types (catches bugs with operations on "dead" values), newtypes (e.g. lets you distinguish sanitized vs unsanitized strings), sum types (avoids bugs where "magic values" (e.g. errors) are treated as "normal values").

Also modern languages like Swift, and Rust to a lesser extent, are treating integer overflow as an error instead of just allowing it (or worse, treating it as UB).

[andrekandre]

typestates are great, but in rust i wonder if it would be more ergonomic and easier to get right if it was officially a feature instead of a pattern you have to implement...?

[steveklabnik]

Amazingly, typestates used to be a headline feature of Rust, in the very, very, very old days. Like, "Wow, Rust is the language that's going to make typestates mainstream!" was a thing people thought when seeing it.

Eventually it was removed. https://pcwalton.github.io/2012/12/26/typestate-is-dead.html

[andrekandre]

  > The reason was that “in practice, it found little use”

thats a real shame...

[jandrese]

Indeed this is the Halting Problem.

[not2b]

The halting problem doesn't prevent correctness proofs, it only means that you get a three-valued answer: proof, counterexample, or too complex to determine. "Too complex to determine" usually means that the code needs to be rewritten to have simpler structure.

And of course the proof is only for those properties that you write down, and you could also have a bug in the spec for those properties.

[sassy_quat]

I guess that's the true Turing Test, can an artificial general intelligence determine the complexity level and relative risk level of infinite loops for an algorithm written for a Turing machine.