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

61–70 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#61

Post by roca »

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…

Rust and Swift are not in the same arena as C++ and Zig. The former offer memory safety and the latter don't --- a critical distinction, since the main reason Rust exists is to provide memory safety in contexts where C++ has traditionally been dominant.

Re: Rust and C++ Interoperability in Chrome

#62

Post by webkike »

Matthias247 wrote: post #46
webkike wrote: post #41

Earlier quoted context omitted.

There are some things that make this better, such as returning pointer types and not returning raw pointers. Returning raw pointers usually means that another function will delete them. I very rarely see pointers handed back from functions being freed caller side

Do you mean references instead of pointers? I'm not familiar of a difference between pointers and raw pointers in C or C++. C++ allows to be more clear: unique_ptrs allow to move ownership, references mean this is definitely not owned, and the remaining questions are around normal pointers. With pure C there is however zero distinction. A pointer can mean ownership is transferred, it is meant to be a reference, it co…

I meant pointers versus types such unique_ptr and shared_ptr

Re: Rust and C++ Interoperability in Chrome

#63

Post by roca »

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.

The Chromium team does not believe you. https://www.chromium.org/Home/chromium-security/memory-safet...

Re: Rust and C++ Interoperability in Chrome

#64

Post by atoav »

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…

I use Rust. Unsafe is okay as long as there is a comment detailing why it is okay. Just like .unwrap() is okay for stuff that never fails.

What is indeed bad is code that sprinkles unsafe all over the place without explanation and if you check a random segment fails to handle common error cases that pure Rust would force you to handle.

Re: Rust and C++ Interoperability in Chrome

#65

Post by mkoubaa »

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.

passing a heap allocated thing from one c++ dll to another doesn't work. it's far better to define a C interface between binaries of any language and reintroduce language specific semantics in a light client library

Re: Rust and C++ Interoperability in Chrome

#66

Post by steveklabnik »

oscargrouch wrote: post #60
steveklabnik wrote: post #53

Earlier quoted context omitted.

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…

Absolutely. I am very interested to see how everything plays out in the future.

Re: Rust and C++ Interoperability in Chrome

#67

Post by kazagistar »

Const-me wrote: post #13

Looks way too complicated. I think the reason is rust is not good at OOP. Compare with my C# to C++ interop library, it can easily pass arbitrary complicated types both ways: https://github.com/Const-me/ComLightInterop

The problems listed aren't the oop, they are the memory and thread safety rules of rust, that prevent all the null pointer dereferencing and leaky memory that a "dumb" C++ wrapper allows.

Re: Rust and C++ Interoperability in Chrome

#68

Post by oscargrouch »

roca wrote: post #61
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…

Rust and Swift are not in the same arena as C++ and Zig. The former offer memory safety and the latter don't --- a critical distinction, since the main reason Rust exists is to provide memory safety in contexts where C++ has traditionally been dominant.

Thats because you have divided the languages by properties and i´ve originally divided them over the class of software that can be written in those languages.

More as "system language" category, where you can code OS´s, JIT compilers, Browsers or any time/memory sensitive kind of software. Thats why they were packed together.

Classically, those sort of things could be only coded in C and C++ as the attempts in doing them in "higher level" languages mostly failed.

Re: Rust and C++ Interoperability in Chrome

#69

Post by SquareWheel »

onebot wrote: post #56

I hope someday maybe we have a browser completely written in Rust. What's the point of using Rust in a C++ code base if C++ is the 800lb gorilla as the article implies. If C++ is so important, then just stick to that?!

Some areas of code are more sensitive than others. Eliminating bugs in areas dealing with encryption, sandboxing, etc may be very beneficial.

Re: Rust and C++ Interoperability in Chrome

#70

Post by kbenson »

> No need for the “unsafe” keyword unless something is known to be less safe than normal C++.

> For a Rustacean, this is controversial - all C++ is unsafe!

Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything?

Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling to a library in some other language will always be unsafe, by definition, because the Rust language cannot vouch for it.

If it makes you feel better, replace "unsafe" in your head (or with a macro) with "rustc_cannot_vouch_for" and carry on with your day. It means the same thing, and isn't really telling you that your C++ code sucks even if it looks like it at first glance, so who cares?

If you really want to reduce the unsafe keyword from being seen in most regular code, you create and interface that maps the C++ function and exposes it as a rust function, and you've hidden away your unsafe usage to one spot per function. If you have enough confidence in your C++ code, there's no downside to this (and if you don't, then maybe you shouldn't be complaining that unsafe is unneeded).

Post reply on HN