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

Rust and C++ Interoperability in Chrome

chromium.org

Post reply on HN
Print view View original

51–60 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#51

Post by steveklabnik »

fullstop wrote: post #15
steveklabnik wrote: post #8

Earlier quoted context omitted.

Rust does not have a textual substitution pre-processor, so like, you can do this sorta kinda but it would be way more involved.

I keep meaning to dive into Rust, but it feels like they've removed so many useful things in the name of safety. I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust. I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point…

Just because we don't have textual substitution doesn't mean we don't have macros. We have a lot of macros!

(It took me a while to write back to you because I am busy writing bare-metal embedded Rust, btw. Including using some macros!)

Re: Rust and C++ Interoperability in Chrome

#52

Post by steveklabnik »

Arnavion wrote: post #24
luizfelberti wrote: post #14

Earlier quoted context omitted.

> Rust does not have a textual substitution pre-processor Is that not pretty much what Rust's procedural macros are? [0] Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways), it can do any arbitrary manipulation of source code, but in a way that is integrated with the compiler and less prone to breaking the program. [0] https://doc.rust-lang.org/referen…

A proc macro would still need to be invoked as either cpp_call! { fn foo() { ... } } or #[cpp_call] fn foo() { ... } The former can be written even with a macro_rules macro. Regardless, both macros have to work by parsing the whole input tokentree `fn foo ( ) { ... }` and emitting it back with an `unsafe` prepended. The macro invocation cannot expand to just `unsafe`.

Yes, this is what I was meaning, thank you.

Re: Rust and C++ Interoperability in Chrome

#53

Post by steveklabnik »

oscargrouch wrote: post #43
kllrnohj wrote: post #40

Earlier quoted context omitted.

> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face. https://bugs.chromium.org/p/project-zero/issues/list?q=produ... This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing. Chromium is an incredibly security-sensitive piece of software, and that really is an…

I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++. Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ cod…

By the way, there's a lot of questions about the methodology of that paper: https://www.reddit.com/r/rust/comments/icaf19/we_tested_the_...

Re: Rust and C++ Interoperability in Chrome

#54

Post by oscargrouch »

mrich wrote: post #50
oscargrouch wrote: post #43

Earlier quoted context omitted.

I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++. Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ cod…

You also have to consider the huge investment that testing takes. Not only person days spent writing tests, but also infrastructure costs for running fuzzers, huge test suites and so on. And although the code base is already there and tested, it constantly changes, so there is no way to just incrementally test it. At some point you have to make some advances in the way you approach software development, not everythin…

It would cost much more to rewrite in Rust.

Again thats why im saying that if the project would start now in 2020, all of those would be pretty good points. Right now is too late for that.

As another example, you can get just the V8 VM for instance. For start, with the ammount of solid code out there it would be nuts to talk over a rewrite..

Now imagine if we add to that, that the knowledge on JIT compilers is so difficult to grasp, that you would also need to have those same great engineers in the new language/platform you are planning the rewrite.

Giving the age of Rust, and giving you already have a bad time of finding those in the much older C++, imagine the time it takes to have the same quality people in Rust.

I know a lot of people are bully about Rust, but in reality things are not that simple.

(On the bright side, is not that hard to taught a C++ engineer to code in Rust)

Re: Rust and C++ Interoperability in Chrome

#55

Post by iulian_r »

oscargrouch wrote: post #43
kllrnohj wrote: post #40

Earlier quoted context omitted.

> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face. https://bugs.chromium.org/p/project-zero/issues/list?q=produ... This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing. Chromium is an incredibly security-sensitive piece of software, and that really is an…

I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++. Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ cod…

> In that research, Rust had the same overall count of bugs and even some 'zero day' sort of ones not any different from C++ and C codebases (maybe just better than the C one).

That's actually not entirely true. One of the problems was the program taking too long to compete due to suboptimal algorithm. The GitHub repo showed that the tests were run using debug version of the Rust binary. It worked fine when people tried to reproduce using the release version.

For the other two problems, not many details were given, but both programs panicked immediately with the given input. That's still better than any kind of undefined behaviour or silent error.

Re: Rust and C++ Interoperability in Chrome

#57

Post by rightbyte »

qppo wrote: post #29
fullstop wrote: post #15

Earlier quoted context omitted.

I keep meaning to dive into Rust, but it feels like they've removed so many useful things in the name of safety. I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust. I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point…

Even modern C++ has eschewed macros for virtually every use case, the only reason I've had to use them (legitimately) has been conditional compilation and some compiler/platform specific issues. Like if you're doing #define PI 3.14159 you're asking to get chirped in code review.

Ye, everyone know it is:

    #define PI 3.1415927410125732421875
that is the float closest to pi or that there is the GNU extension USE_FUNKY_DEFINES-something with M_PI for cmath. (I know you meant constexpr:ions).

Re: Rust and C++ Interoperability in Chrome

#58

Post by jcranmer »

coder543 wrote: post #42
lalaithion wrote: post #39

Earlier quoted context omitted.

I disagree; All of the things you say about C++ code also apply to unsafe Rust code. There's an unsafe keyword that allows using that unsafe code, and when you use it, you are asserting to the compiler that "I promise this code is actually being used in a safe way". All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being us…

> All of the things you say about C++ code also apply to unsafe Rust code. Which is why unsafe is considered a code smell, and why people in the Rust community get upset when unsafe is used unnecessarily. That's why some people might find it controversial to hide the unsafety of the C++ code being used here. I've used Rust professionally for years, and I don't remember ever having to write any unsafe code in a profes…

> Those are the only things unsafe Rust can do that safe Rust can't. It doesn't turn off the borrow checker or anything else.

You can do serious damage with those things though. One tactic I have done is to expand the lifetime of a reference by laundering it through a raw pointer, since the function to convert a raw pointer to a reference allows you to choose any lifetime you want.

Re: Rust and C++ Interoperability in Chrome

#59

Post by rightbyte »

roblabla wrote: post #11
steveklabnik wrote: post #8

Earlier quoted context omitted.

Rust does not have a textual substitution pre-processor, so like, you can do this sorta kinda but it would be way more involved.

macro_rules! cpp_call { ($($tt:tt)*) => { unsafe { $($tt)* } } } Yeah, not pretty, but it works :P

Nature finds its ways.

Seriously though, maybe comment annotation would be better than abusing the macros like that. I though there was a more direct cpp way. (Edit: As in the c preprocessor, not C++.)

Re: Rust and C++ Interoperability in Chrome

#60

Post by oscargrouch »

steveklabnik wrote: post #53
oscargrouch wrote: post #43

Earlier quoted context omitted.

I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++. Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ cod…

By the way, there's a lot of questions about the methodology of that paper: https://www.reddit.com/r/rust/comments/icaf19/we_tested_the_...

To be fair Steve, i didnt use this as to invalidate the assumptions on Rust. Just that we need to be more carefull to just take things for granted.

Im not even taken this research for granted, and are waiting for further work to really prove the points, or even going against them.

Im just using as a cautionary tale for people going too fast on some assumptions, and not taking care to study sample by sample.

I have no doubt that Rust have a great future ahead of it. But it will take more time and lines of code to turn all of those wishes people have into reality.

Post reply on HN