4 ms·

One thing that people say is that "Rust frontloads your problems". C++ might be a bit easier to get your head around to start with, but as the complexity of wha

One thing that people say is that "Rust frontloads your problems". C++ might be a bit easier to get your head around to start with, but as the complexity of what you're building grows you will discover the 'joy' of debugging segfaults and race-conditions. Rust has some type-system complexity to get your head around. It's not as painful as it looks (when you're just reading it rather than trying to do it) but there is a hump of understanding there that you have to get over. Once you've done that though, Rust then helps you so much more in dealing with the 'long tail' of difficult problems. Another way of looking at it is that there are a load of things that you can silently get wrong in C++. There are good practices that help you not screw up e.g. you have to learn how to think about who has pointers to what and how long they live. Rust forces you to think about that stuff from day 1 - the compiler requires you to prove to it that everything is good. It's a bit painful to start with, but it's a good thing overall.

torrent 5y ago
having segfault is the best you can have: it tells you explicitly that something is wrong with your program. in other languages the same kind of error may result in stale data and the GC does not collect the data and the memory consumption grows slowly. You will notice the problem much later. Np language can solve the inability of writing a correct program. Do you believe if your Rust program compiles it is free of errors??
- rkangel 5y ago
  > having segfault is the best you can have: it tells you explicitly that something is wrong with your program. If you get one. In Rust if I overrun the bounds of an array I will get a panic. It is deterministic and specified, and the stacktrace will tell me which array I overran. In C/C++ I get no such guarantees - the behaviour is explicitly undefined. If you are LUCKY you'll get a segfault there and then. For one off the end of an array that's unlikely, particularly if it's on the stack. You're much more likely to silently corrupt some data. The program will probably eventually segfault out, but there's no guarantee it's anywhere near the cause, and it could have done anything in the meantime. If you're on embedded it's even worse - no segfaults there at all. No, if my Rust program compiles it is not necessarily free from errors. It is almost certainly free from memory errors though. Memory errors are problematic, hard to debug and the largest cause of security holes.

torrent 5y ago

having segfault is the best you can have: it tells you explicitly that something is wrong with your program. in other languages the same kind of error may result in stale data and the GC does not collect the data and the memory consumption grows slowly. You will notice the problem much later. Np language can solve the inability of writing a correct program. Do you believe if your Rust program compiles it is free of errors??

rkangel 5y ago
> having segfault is the best you can have: it tells you explicitly that something is wrong with your program. If you get one. In Rust if I overrun the bounds of an array I will get a panic. It is deterministic and specified, and the stacktrace will tell me which array I overran. In C/C++ I get no such guarantees - the behaviour is explicitly undefined. If you are LUCKY you'll get a segfault there and then. For one off the end of an array that's unlikely, particularly if it's on the stack. You're much more likely to silently corrupt some data. The program will probably eventually segfault out, but there's no guarantee it's anywhere near the cause, and it could have done anything in the meantime. If you're on embedded it's even worse - no segfaults there at all. No, if my Rust program compiles it is not necessarily free from errors. It is almost certainly free from memory errors though. Memory errors are problematic, hard to debug and the largest cause of security holes.