3 ms·

Rust definitely has a different feeling of mastery than other languages, due to the fact that most if not all bugs are caught during the compilation phase. In

Rust definitely has a different feeling of mastery than other languages, due to the fact that most if not all bugs are caught during the compilation phase. In other languages I like, I reach a point where I’m generally confident my code will compile before I ask it to. In Rust, for all but the most trivial logic, the compiler will usually have several things to say. However, I usually feel like the compiler is guiding me towards a simpler/more idiomatic/better way of doing things, and the compiler is more strict simply because Rust is so well-equipped for static compile-time analysis. So fret not, the borrow checker and all the other checks that happen when writing Rust exist precisely because these things are so painful and complex to reason about as a human. The compiler is your colleague, not your boss!

eventhorizonpl 4y ago
"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.
- wwalexander 4y ago
  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.
- yakubin 4y ago
  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-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...> [2]: <https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit>
okwubodu 4y ago
I find Rust much easier to hold in my head as well. It’s reduced the need for mid-session, “just-in-case” compilations to the point that building sometimes feels like a formality.

eventhorizonpl 4y ago

"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.

wwalexander 4y ago
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.
yakubin 4y ago
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-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...> [2]: <https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit>

okwubodu 4y ago

I find Rust much easier to hold in my head as well. It’s reduced the need for mid-session, “just-in-case” compilations to the point that building sometimes feels like a formality.