4 ms·

> I can tell you that bad programmers can write bad code in Rust. Of course. The question rust users seem to put forth is that bad programmers write _better_ (

> I can tell you that bad programmers can write bad code in Rust. Of course. The question rust users seem to put forth is that bad programmers write _better_ (not good) rust code than C code. That bad programmers write bad code is to expected. That is, after all, a likely explanation for why they're bad.

nneonneo 4y ago
I would argue that the type system does make it somewhat more difficult for bad programmers to do egregiously bad things in the language. A carefully written library can be quite difficult to misuse (at least, without panics or using unsafe code in the user code, both of which are easy to catch in code review). Rust has no null/nil pointers. Instead, it has nullable types (Option<T>), which are harder to misuse. If you want to "dereference" a Option, you either use unwrap() (which panics) or you handle the None case properly. While `.unwrap().foo()` is still just as crashy as an unguarded `x->foo()` in other languages, a code review can catch misuse of .unwrap() much more readily than a missing null/nil check. As another example, the Send/Sync traits provide strong guarantees about thread safety; using these traits properly lets you make data structures that cannot be misused in a multithreaded program. Although deadlock is still possible (hello, halting problem), many types of data races are simply eliminated.
- Taywee 4y ago
  `x->foo()` in C++ often isn't just "crashy", but undefined behavior. See https://en.cppreference.com/w/cpp/utility/optional/operator https://en.cppreference.com/w/cpp/utility/optional/operator* > The behavior is undefined if *this does not contain a value. I'll take crashes over "probably does the wrong thing" any day.
- optionalsquid 4y ago
  > While `.unwrap().foo()` is still just as crashy as an unguarded `x->foo()` in other languages I think it is also worth noting that unwrap itself is much safer than an unguarded `x->foo()`, since it doesn't involve undefined behavior. Meanwhile an unguarded `x->foo()` allows compiler to assume that x is never null and consequently do things that the programmer wouldn't expect. The recent post on undefined behavior [1] had a (to me) quite shocking example of that [2]. So while bad Rust programmers misusing unwrap get crashes, they won't get nasal demons. [1] https://news.ycombinator.com/item?id=33771922 https://news.ycombinator.com/item?id=33771922 [2] https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior...

nneonneo 4y ago

I would argue that the type system does make it somewhat more difficult for bad programmers to do egregiously bad things in the language. A carefully written library can be quite difficult to misuse (at least, without panics or using unsafe code in the user code, both of which are easy to catch in code review). Rust has no null/nil pointers. Instead, it has nullable types (Option<T>), which are harder to misuse. If you want to "dereference" a Option, you either use unwrap() (which panics) or you handle the None case properly. While `.unwrap().foo()` is still just as crashy as an unguarded `x->foo()` in other languages, a code review can catch misuse of .unwrap() much more readily than a missing null/nil check. As another example, the Send/Sync traits provide strong guarantees about thread safety; using these traits properly lets you make data structures that cannot be misused in a multithreaded program. Although deadlock is still possible (hello, halting problem), many types of data races are simply eliminated.

Taywee 4y ago
`x->foo()` in C++ often isn't just "crashy", but undefined behavior. See https://en.cppreference.com/w/cpp/utility/optional/operator https://en.cppreference.com/w/cpp/utility/optional/operator* > The behavior is undefined if *this does not contain a value. I'll take crashes over "probably does the wrong thing" any day.
optionalsquid 4y ago
> While `.unwrap().foo()` is still just as crashy as an unguarded `x->foo()` in other languages I think it is also worth noting that unwrap itself is much safer than an unguarded `x->foo()`, since it doesn't involve undefined behavior. Meanwhile an unguarded `x->foo()` allows compiler to assume that x is never null and consequently do things that the programmer wouldn't expect. The recent post on undefined behavior [1] had a (to me) quite shocking example of that [2]. So while bad Rust programmers misusing unwrap get crashes, they won't get nasal demons. [1] https://news.ycombinator.com/item?id=33771922 https://news.ycombinator.com/item?id=33771922 [2] https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html https://kristerw.blogspot.com/2017/09/why-undefined-behavior...