6 ms·
> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. T
by Q6T46nT668w6i3m 12y ago
> Despite all this, Rust is going to be a very important language, because it solves the three big problems of C/C++ that causes crashes and buffer overflows. The three big problems in C/C++ memory management are "How big is it?", "Who owns and deletes it?", and "Who locks it?". C/C++ deals with none of those problems effectively. Rust deals with all of them, without introducing garbage collection or extensive run-time processing. This is a significant advance.
What? C++11/14 solves these issues.
- unfamiliar 12y agoCare to elaborate? I don't see how it does.
- azakai 12y agoYes, in particular, iterator invalidation (problem 2 in that list) seems unsolvable in C++, as far as I can see. I've hit iterator invalidation in a new c++11 codebase. Perhaps c++14 offers something to help it that I'm not aware of? edit: "unsolvable" in the sense of the language making it impossible,
- Q6T46nT668w6i3m 12y agoYeah. It isn’t enforced, but it’s easier to mitigate.
- pcwalton 12y ago> What? C++11/14 solves these issues. You're right that C++ provides a solution to the first two, but C++ locking via std::mutex isn't done in the same way as Rust: in Rust the mutex owns the data and prevents you from getting access to it unless you lock. std::mutex, however, is a separate value from the data it protects and it's up to you to coordinate access to that data. I would also argue that Rust is a better solution to the first two issues. Modern C++ does not solve the problem of use-after-free (dangling references and invalid iterators are very possible, and common in large codebases). This is something that I don't believe C++ can solve without becoming a radically different language. Furthermore, Rust forces you to use the right patterns unless you type "unsafe": this is, again, important for security, reliability, and developer productivity, reducing the amount of time you spend in the debugger.
- Q6T46nT668w6i3m 12y agoFair points Rust’s synchronization primitives are immature — they’ve been rewritten once or twice in the past year or so — but cool from a usability perspective. edit: oh, hello pcwalton. I suspect you knew this already. :P
- Ygg2 12y ago[Citation needed]
- Q6T46nT668w6i3m 12y ago?
- Ygg2 12y agoBased on what did you concludes that?
- copsarebastards 12y agoAlso, it's worth noting that "C++ provides a solution" is not "C++ solves these issues". Somewhere in any C++ codebase of significant size, someone has done it wrong and the compiler isn't going to tell you where.
- zanny 12y agoMy simplification of matters is that while C++ can now do everything right, it still easily lets you do everything wrong. Rust compels correctness, so for any project where you can't trust your coworkers aptitude towards correctness (and that is to say you even trust your own) Rust is an insane productivity booster. We could have avoided millions of hours of work and thousands of zero day and system destroying bugs if we had OS cores written in a language like Rust.
- ssalazar 12y ago> so for any project where you can't trust your coworkers aptitude towards correctness So, for any non-trivial project. People will make mistakes, no matter how skilled or experienced they are. Catching these mistakes at compile-time can be a huge gain for security and stability. Though it remains to be seen is what kind of maintenance/development burden these constraints introduce over the longer term lifecycle of a software project.
- pjmlp 12y agoOnly if you are allowed to use said features. Many C++ codebases out there are still pre C++98. I like C++, but I don't see the opportunity where to use C++14 outside hobby projects.
- Q6T46nT668w6i3m 12y ago> I like C++, but I don't see the opportunity where to use C++14 outside hobby projects. Sure, but I’ve encountered some notable exceptions: LLVM projects (C++11), Playstation 4 games (C++11/14), QT5 (C++11) projects, et al.
- pjmlp 12y agoNone of those are the typical corporation code that most of us are exposed to.
- Q6T46nT668w6i3m 12y agoMaybe? I was addressing your “I don’t see the opportunity where to use C++14 outside hobby projects.” Compilers, games, and operating system components are archetypical systems software.
- pjmlp 12y agoHow many Fortune 500 do you see writing those?
- djur 12y agoMicrosoft, Apple, IBM, Amazon?
- pjmlp 12y agoHow many C++ developers can apply to work on those world wide? The point isn't what companies are using C++11 or C++14, rather what companies for the common C++ developer on the street. Sometimes HN seems to think SV is the only place where programmers live.
- scott_s 12y agoNo; modern C++ provides the tools for which disciplined use solves these issues. The problem is that one can silently subvert that discipline, and still introduce memory errors. Rust enforces memory safety at the language level. C++ itself does not "know" about memory safety. This difference, to me, is huge. You can still opt out of memory safety in Rust through unsafe regions, but the fact that Rust provides memory safety guarantees to non-unsafe regions is, to me, a change in kind, not degree. When the only thing enforcing memory safety is disciplined use, it's still too easy to make a mistake.
- deleted 12y ago[deleted]
- JoshTriplett 12y ago> What? C++11/14 solves these issues. Sure, it solves some of those problems if you use exclusively smart pointers and vectors, and never use the built-in language pointers and arrays. What forces you to do so, when '*' and "new" and [] are right there? Rust pushes you towards the right solution by requiring an "unsafe" block if you use raw pointers or arrays. That doesn't prevent you from using them (such as in the implementations of higher-level constructs or FFI calls), but it does hint that they're the wrong solution for everyday programming.