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

31–40 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#31

Post by oscargrouch »

As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all.

Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts)

The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work.

I guess maybe Google wants to employ good Rust enginneers and need to have some "playground" for them.

Swift on the other way, will have native C++ interop, and soon will give the ability to manage the memory ownership the same way C++ and Rust does (not just defaulting to ref-count)..

Once Swift have those properties we will have one more good contender in the same arena as C++, Rust and Zig.

Re: Rust and C++ Interoperability in Chrome

#32

Post by stefan_ »

Paul-ish wrote: post #25

Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX. Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.

You need to answer "who frees it" in Rust, too, it just doesn't allow you to screw it up.

Re: Rust and C++ Interoperability in Chrome

#33

Post by [deleted] »

oscargrouch wrote: post #31

As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all. Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts) The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work. I guess maybe Google wants to employ good Rust enginneers and need to have some…

[deleted]

Re: Rust and C++ Interoperability in Chrome

#34

Post by nilkn »

oscargrouch wrote: post #31

As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all. Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts) The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work. I guess maybe Google wants to employ good Rust enginneers and need to have some…

I doubt the point is to offer people a playground but rather to find a way to write new code in a language that is memory safe by default. Browsers are notoriously plagued by bugs related to memory safety so there’s quite a lot of motivation for at least considering this path.

Re: Rust and C++ Interoperability in Chrome

#35

Post by rightbyte »

Paul-ish wrote: post #25

Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX. Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.

Surely C++ exceptions and destructors has to be the main issue for interoperation?

I've done to many C++ wrappers with C linkage of C++ libs to call from C, that convert exceptions to error codes and free_obj() wrappers to run destructors.

Re: Rust and C++ Interoperability in Chrome

#36

Post by modeless »

oscargrouch wrote: post #31

As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all. Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts) The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work. I guess maybe Google wants to employ good Rust enginneers and need to have some…

The security benefits of Rust outweigh those concerns. Almost all C++ code in Chromium is security sensitive. Even if it is sandboxed it can be part of an exploit chain to get to a sandbox escape. Adopting more secure languages should be a long term goal of the project.

Re: Rust and C++ Interoperability in Chrome

#37

Post by oscargrouch »

nilkn wrote: post #34
oscargrouch wrote: post #31

As someone that deals with a chromium-based codebase everyday, i dont think this is a good idea at all. Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts) The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work. I guess maybe Google wants to employ good Rust enginneers and need to have some…

I doubt the point is to offer people a playground but rather to find a way to write new code in a language that is memory safe by default. Browsers are notoriously plagued by bugs related to memory safety so there’s quite a lot of motivation for at least considering this path.

That is the problem with default narratives, they dont adapt well to every case.

Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face.

And no matter what wonders Rust promisses, a lot of bugs would get back there in case of rewriting things.

Rust can make a very good point when the thing to be rewritten is in C (if is not a billion dollar codebase like Linux). But with big codebases, well written and modern C++ it doesnt make sense at all.

I get it why someone would start a new project in Rust though.. but the things dont add up when we talk about big codebases already coded with good C++ practices.

Re: Rust and C++ Interoperability in Chrome

#38

Post by modeless »

bluejekyll wrote: post #4

> This seems to present some C++/Rust interoperability challenges which nobody else has faced. Is this different from the Firefox integration with Rust in some meaningful way? It looks like the cxx library is going to be critical for this. I’m curious how helpful others have found cxx for interop with C++? > For a Rustacean, this is controversial - all C++ is unsafe! But “unsafe” should be a really bad code smell. If…

Seems like the difference is the level of friction the project is willing to take on in order to support Rust.

Re: Rust and C++ Interoperability in Chrome

#39

Post by lalaithion »

coder543 wrote: post #16
rightbyte wrote: post #5

Earlier quoted context omitted.

Can't you just do a: #define CPP_CALL unsafe in the Rust equivalent to annotate "unsafe" cpp calls from Rust? "No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist." This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.

Really, your text macro substitution is missing the broader point. Hiding the word "unsafe" doesn't make it any less unsafe. The Rust compiler can't guarantee that the C++ code being called doesn't have use-after-free bugs or buffer overflows. The Rust compiler can't guarantee that pointers being returned from C++ code aren't just wild pointers that point in the middle of nowhere. The Rust compiler can't guarantee th…

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 used in a safe way".

Re: Rust and C++ Interoperability in Chrome

#40

Post by kllrnohj »

oscargrouch wrote: post #37
nilkn wrote: post #34

Earlier quoted context omitted.

I doubt the point is to offer people a playground but rather to find a way to write new code in a language that is memory safe by default. Browsers are notoriously plagued by bugs related to memory safety so there’s quite a lot of motivation for at least considering this path.

That is the problem with default narratives, they dont adapt well to every case. Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems yo…

> 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 excellent fit for Rust. It's not a boogeyman argument and the Chromium team themselves are the ones pursuing it, it's not being forced on them.

Post reply on HN