71–80 of 242 posts
I have actually started to do this to see for myself how much work it would be http://blog.dkhenry.com/2016/02/17/deciding-to-rewrite-getad...
C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.
I will be happy if Rust's main impact on history will have been to showcase how to get those safety features into a practical language, and by extension improvements to C++, but I still think that the steps C++ is taking seem a lot less safe than what Rust has achieved by completely ignoring backward compatibility with C++98. See, for example, the compiler-enforced concurrency safety that Rust provides. I haven't read the core guidelines recently or in depth, but IIRC that's not a stated goal of the project.
And with that mastery: what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle. For instance:
http://news.mit.edu/2016/faster-automatic-bug-repair-code-er...
To detect vulnerabilities people need to be careful and follow best practices. If they can't do that well.. replace the people with software that's better and more efficient than the people. :)
I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that…
Rewriting in Rust, increases the contributor pool for these project from some x to some y. Where x is the subset of people in [1, 2, 3, 4, 5] and y is the subset of people in [1, 4]:
1. Who are eager and have time to help
2. Who know manual memory management really well (also diligent enough to use that knowledge appropriately) [Made redundant by compiler]
3. Who can successfully build, link and test C code on multiple platforms [Made trivial by Cargo]
4. Have appropriate domain knowledge
5. Are not afraid to refactor "working code". [Made better through first class testing, the compiler and community mindset]
There is also the aspect that experts get a dramatic boost to their productivity, reducing their time needed, and therefore reducing the level of incentives needed.
Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. We live in a C world and I don't see that…
C's primary design goal that overrode everything else was easy implementation. In order to keep a dumb compiler, the preprocessor was used instead of a proper module system. For the same reasons, the standard library is full of non-reentrant functions relying on global state, unbounded string manipulation functions or bounded string functions with ambiguous off-by-one properties, vaguely defined data types and so on.
If there's one reason to do away with C, is to do away with all the stubborn programmers who clutch their copy of K&R and think everything must be done in the "C way". To paraphrase Linus' on C: you'd want to avoid C just to avoid this type of C programmers. They could be amazing coders, but not if you care about security (and you should).
Earlier quoted context omitted.
> A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
Agreed, the hope is that the combination of Rust + a rewrite, you'd be in a MUCH better place than where we are now. I think an interesting question is, why are there so many contributors to the Linux Kernel in comparison to something like glibc? Both, I'd argue, are equally foundational.
Earlier quoted context omitted.
I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is…
> how hard do folks think it would be to make a C -> Rust transpiler? Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.
Again, this might be a terrible idea, but I'd be curious to hear from anyone that has experience with this sort of porting...
Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C. And with that mastery: what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle. For instance: http://news.mit.edu/2016/faster-automatic-bug-repair-code-er... To detect vulnerabilities people need to be…
Earlier quoted context omitted.
I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's…
I don't understand the difference between #1 and #2, or why Rust helps with one and not the other. If memory safety is enforced, it's enforced. > Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.
Due to this issue that the rust authors seem unwilling to address, I fully recommend against rust for the precise roles it's intended to be good at.