alt Hacker News> But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me.
In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect.
Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that.
> Rust cannot prevent incorrect code, nor is this possible (halting problem).
Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround.
Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.
Of course, but many languages do many of these things, and have for decades. C is an outlier for not having them, and many big apps use C++ over C for this reason.
Rust's contribution is static resource-use-correctness. Of course, it also implements the other features very well. But if you do not talk about these things in precise terms, it will be harder to convince people to embrace Rust adoption.
Thankfully, Rust is not doing bad for itself in terms of adoption, so what do I know! :)
But it is what kept me from using it for a long time.