Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewrite Everything in Rust

robert.ocallahan.org

Post reply on HN
Print view View original

111–120 of 242 posts

Re: Rewrite Everything in Rust

#111

Post by dbaupp »

iherbig wrote: post #105
shmerl wrote: post #99

Earlier quoted context omitted.

C++ still can't prevent things like iterator invalidation which are impossible in Rust. While I like modern C++, Rust really addresses a lot of problems with the proper design from the ground up, which C++ can't do. What Rust so far lacks is better OOP mechanisms. C++ beats Rust in that. For instance Rust is still missing something like virtual structs. See https://github.com/rust-lang/rfcs/issues/349

Genuine question: What do virtual objects enable that cannot be done through the Trait system?

I believe they're equally expressive, but the existing trait approach has a different run-time/memory profile. The issue linked in the parent comment has some info/links, and, http://smallcultfollowing.com/babysteps/blog/2015/10/08/virt... is the latest word on the subject (including various links).

Re: Rewrite Everything in Rust

#112

Post by kibwen »

daurnimator wrote: post #80

Rust has major unsafeness around low memory that make it unsuitable in this libc type role. See: https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_ru... and https://lwn.net/Articles/644708/ 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.

You misunderstand the role of Rust's standard library. For "libc type roles" you'd be using libcore, which is a subset of the standard library that does no allocation whatsoever, and allows you to define your own allocators and do whatever you like on allocation failure.

Re: Rewrite Everything in Rust

#113

Post by [deleted] »

unscaled wrote: post #90
dikaiosune wrote: post #72

Earlier quoted context omitted.

But the core guidelines are optional -- which means that you'll still have the entirety of C/C++ footgun hell to watch out for, and decades of outdated teaching and learning materials. And very large codebases which could not be easily ported to a compiler that enforced those guideines. 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 langua…

Looking at the presentation it looks like you can borrow a non-const reference (in rust parlance) several times, so there's no concurrency guarantee. You would have to break compatibility with too much existing code to get the same level of strictness as Rust, so that's reasonable, but yeah, it's hard to imagine that C++ will be as safe as Rust. I'm glad these features are being pushed through though.

[deleted]

Re: Rewrite Everything in Rust

#114

Post by mattip »

carussell wrote: post #26

Do user studies. It's pretty much unheard of, but nearly every open source project would benefit far more from a week of watching potential contributors trying to get up to speed than it would from making sure the project roadmap is delivered a week sooner. That's my claim for projects in general, and what you're asking for re Rust is a little different, but the approach can applied there, too. Focus on everything fr…

Has this been done for any project? I am interested in seeing the setup used, resulting reports, and changes instituted

Re: Rewrite Everything in Rust

#115

Post by kibwen »

thinkpad20 wrote: post #20

I don't know much about glibc, but since you can call rust from C and vice versa, it seems like you could reimplement a few functions at a time, incrementally phasing out C code and replacing it with rust. Assuming, of course, that you agree with the author's thesis. This approach lets you reuse the same tests and do things like benchmarking etc to make sure the implementation is performant and compliant.

This is exactly how Firefox is approaching it. Identify the most security-critical bits, wall them off into their own component, and rewrite it in Rust.

Re: Rewrite Everything in Rust

#116

Post by bjz_ »

ktRolster wrote: post #22
pcwalton wrote: post #11

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.

Memory safety problems are the low-hanging fruit of vulnerabilities. A re-write by unskilled programmers will not guarantee the code is safe, because they will introduce many other kinds of vulnerabilities.

By removing memory safety bugs, it allows reviewers to focus on the more important sources of vulnerabilities - the things that the compiler can't check. On that front, it is also worth noting that Rust has a much richer type system than C or C++, and can be leveraged to craft domain models that catch many more bugs at compile time.

With all of that said however, I agree with you that it would be foolish to think that a rewrite would not be open to lots of potential vulnerabilities. At the moment might be prudent to continue to use and support the current libraries, but to also support efforts like rust-crypto in order to prepare for the future.

Re: Rewrite Everything in Rust

#117

Post by bjz_ »

kibwen wrote: post #115
thinkpad20 wrote: post #20

I don't know much about glibc, but since you can call rust from C and vice versa, it seems like you could reimplement a few functions at a time, incrementally phasing out C code and replacing it with rust. Assuming, of course, that you agree with the author's thesis. This approach lets you reuse the same tests and do things like benchmarking etc to make sure the implementation is performant and compliant.

This is exactly how Firefox is approaching it. Identify the most security-critical bits, wall them off into their own component, and rewrite it in Rust.

Yes! And the reverse has happened with Servo. Originally it was mainly a bag of C libraries with some layout code, then gradually they began swapping the pieces out for the Rust counterparts. This is how new software can be written - bootstrapping off the C infrastructure, then gradually transitioning more and more into Rust land.

Re: Rewrite Everything in Rust

#118

Post by jonalmeida »

_b wrote: post #67

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.

Full support for Concepts[1] would also further add to the compiler checks as well. Although I believe this hasn't be confirmed when it'll come into the standard. Essentially, they're just Rust Traits.

[1]: https://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29

Re: Rewrite Everything in Rust

#119

Post by giancarlostoro »

panic wrote: post #9

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…

> We need to have incentives for maintaining this foundational software.

BountySource?[0] I'm not affiliated with them, but they seem to fit that kind of spot from what I've seen so far.

[0]: https://www.bountysource.com/

Re: Rewrite Everything in Rust

#120

Post by _greim_ »

There's a perverse incentive in software, where toolsets requiring memorization of arcana not inherent to the problem domain but inherent to how the tool maps onto the problem domain, will generate irrational loyalty among its users. Our toolsets and the investments we make in them really do become a way of life, and fuck the world if it tries to get us to change.
Post reply on HN