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

91–100 of 242 posts

Re: Rewrite Everything in Rust

#91

Post by cheez »

ubernostrum wrote: post #84
_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.

For most applications, moving to modern C++ is going to be a better option than rewriting in Rust. I wouldn't bet on that. Companies which go with a language like C++ don't do it for "safety" or "performance" or reasons like that (at least, most of the time they don't). They go with it because they can get something written once, then run it for the next half-century and only have to spend engineering time on new fea…

Who rewrote in Lua instead of Python?

Re: Rewrite Everything in Rust

#92

Post by dikaiosune »

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.

Absolutely, I didn't mean to say that improving C++ is bad (we sure as hell need it, esp. given how much of the world runs on C++), and C++14 and 17 have many exciting things coming. I just didn't think it was fair to say that the new standard(s) "steals nearly all of Rust's safety thunder," when several core promises of Rust's safety model aren't possible in C++ if you maintain backwards compatibility.

Re: Rewrite Everything in Rust

#93

Post by cmrx64 »

panic wrote: post #57
unscaled wrote: post #54

Earlier quoted context omitted.

OP article was specifically talking about Rustbelt as one tool you would be able to use in the future to mitigate the risks posed by the unsafe code you do have. But in general, I think that entire idea is that as more code moves to memory-safe languages, the less need we have for unsafe sections. Ideally, once the kernel itself can be written in a memory safe language, everything running on top of that wouldn't need…

It's not decades away! Check out https://sel4.systems .

And, relatedly, https://robigalia.org/

Re: Rewrite Everything in Rust

#94

Post by rubiquity »

bluejekyll wrote: post #64
rubiquity wrote: post #18

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…

> an avid Rust user puts their money where their mouth is There are lots of people doing this. Look at crates.io. I decided to write a new fully compliant DNS server and client, trust-dns. I work on it in my spare time (it's time not money), which is hard with two kids. I've learned a few things. It's hard to get it done. There's a lot to learn from the rfc's. Just because it's Rust, doesn't mean it's easy. There are…

Your entire post reinforces the idea that in my list of challenges to writing safe software that #1 is far more the issue than #2.

Re: Rewrite Everything in Rust

#95

Post by smrq »

_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.

I feel like C++ has turned into programming language Katamari Damacy. I wonder what it will look like when it rolls up Lisp?

Re: Rewrite Everything in Rust

#96

Post by yoklov »

smrq wrote: post #95
_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.

I feel like C++ has turned into programming language Katamari Damacy. I wonder what it will look like when it rolls up Lisp?

It already has a turing complete pure functional sublanguage in it's templates. Probably closer to the worlds worst ML than a lisp, but it's still along the same lines.

Re: Rewrite Everything in Rust

#97

Post by asdfaoeu »

ubernostrum wrote: post #84
_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.

For most applications, moving to modern C++ is going to be a better option than rewriting in Rust. I wouldn't bet on that. Companies which go with a language like C++ don't do it for "safety" or "performance" or reasons like that (at least, most of the time they don't). They go with it because they can get something written once, then run it for the next half-century and only have to spend engineering time on new fea…

To be fair it's better than "rewrite everything in Rust"

Re: Rewrite Everything in Rust

#98

Post by hermanradtke »

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.

Based on my reading, only the std library has the behavior unsuitable for a libc type role. I would think a libc replacement would use #[no std] and have the finer grained control.

Re: Rewrite Everything in Rust

#99

Post by shmerl »

_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.

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

Re: Rewrite Everything in Rust

#100

Post by roca »

_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.

It remains to be seen whether that approach will guarantee memory safety. Last I checked, it had gaping soundness holes related to aliasing. (Note: most of the complexity and innovation in Rust is about controlling aliasing.)

When all the soundness holes are closed, then we'll have to evaluate whether it's usable to program in. At the very least, Rust is years ahead here.

Even if those hold up, you have to consider whether rewriting your C++ code to fit the safe subset is actually worthwhile, compared to rewriting in Rust which gives you additional benefits.

Post reply on HN