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

141–150 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#141

Post by dllthomas »

atoav wrote: post #64
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.

> Just like .unwrap() is okay for stuff that never fails.

Never fails, and will also never fail in the future as other code changes. There are certainly situations where you can be sufficiently confident of that, but it's something to think about.

Re: Rust and C++ Interoperability in Chrome

#142

Post by saurik »

codeflo wrote: post #91
steveklabnik wrote: post #89

Earlier quoted context omitted.

> For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++. This is well-defined, as being dropped in the order that they are declared.

I didn't want to suggest it's undefined, I said weird. In C++, it's reverse declaration order, and that's important because destruction exactly mirrors construction. Arguably, Rust is completely wrong here, but my experience is that this problem doesn't come up in idiomatic Rust all that often because fields can't depend on each other anyway. And I'm wildly speculating of course, but something like that might be more…

Just because fields can't depend on each other in code doesn't mean that the side effects of those fields don't matter: Rust is only guaranteeing memory safety, not semantic safety... like, if you are tracking file handles or networked objects or bicycle messengers, it can easily (and even often) be very important that objects deconstruct in the reverse stacking order of their construction. I am so glad I read your comment here as I could easily see myself one day starting to use Rust and going insane from this decision :(. (The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property.)

Re: Rust and C++ Interoperability in Chrome

#143

Post by mitchtbaum »

M2Ys4U wrote: post #137
fgdfgddfg wrote: post #106

Earlier quoted context omitted.

That was the goal with Servo, but Mozilla axed them https://twitter.com/directhex/status/1293352458308198401

Servo was always a research project around writing a rendering engine and not an attempt to create a whole new browser product.

Webrender would work better as the complete OS interface than as an engine for one browser/app.

Re: Rust and C++ Interoperability in Chrome

#144

Post by mkoubaa »

jcelerier wrote: post #131
mkoubaa wrote: post #65

Earlier quoted context omitted.

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

> passing a heap allocated thing from one c++ dll to another doesn't work. this is chromium, everything is built from source with the same compiler, there is zero issue with doing that. This only does not work when using a DLL built with, say, visual studio 2008 and another built with 2015.

Actually a DLL built with the same version but with either a different c runtime library (e.g. MD or MT) or a different target (release or debug) will have this problem

Re: Rust and C++ Interoperability in Chrome

#145

Post by mkoubaa »

ncmncm wrote: post #111
mkoubaa wrote: post #65

Earlier quoted context omitted.

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

You must be talking about Microsoft stuff not applicable here.

Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash.

The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium

Re: Rust and C++ Interoperability in Chrome

#146

Post by kbenson »

saurik wrote: post #142
codeflo wrote: post #91

Earlier quoted context omitted.

I didn't want to suggest it's undefined, I said weird. In C++, it's reverse declaration order, and that's important because destruction exactly mirrors construction. Arguably, Rust is completely wrong here, but my experience is that this problem doesn't come up in idiomatic Rust all that often because fields can't depend on each other anyway. And I'm wildly speculating of course, but something like that might be more…

Just because fields can't depend on each other in code doesn't mean that the side effects of those fields don't matter: Rust is only guaranteeing memory safety, not semantic safety... like, if you are tracking file handles or networked objects or bicycle messengers, it can easily (and even often) be very important that objects deconstruct in the reverse stacking order of their construction. I am so glad I read your c…

> The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property

Don't you just define a destructor[1] and make it explicit? Or maybe I'm missing something subtle here?

1: https://doc.rust-lang.org/reference/destructors.html

Re: Rust and C++ Interoperability in Chrome

#147

Post by ncmncm »

mkoubaa wrote: post #145
ncmncm wrote: post #111

Earlier quoted context omitted.

You must be talking about Microsoft stuff not applicable here.

Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash. The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium

Now you are changing the subject. Allocation, which was the subject, happens the same way on either side of gcc's C++11 boundary. The C++11 break was required by the ISO Standard issued in 2011.

The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, release or debug, optimized or not.

It is possible to deliberately vary ABI with compiler options, but nobody uses those for shared libraries they distribute, for obvious reasons, with the unique exception of choosing pre-C++11 vs post-C++11 ABI.

Re: Rust and C++ Interoperability in Chrome

#148

Post by mkoubaa »

ncmncm wrote: post #147
mkoubaa wrote: post #145

Earlier quoted context omitted.

Not true. GCC broke compatibility with the memory layout of are string at c++11 and passing those between DLLs with versions of GCC on either side of that change will crash. The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium

Now you are changing the subject. Allocation, which was the subject, happens the same way on either side of gcc's C++11 boundary. The C++11 break was required by the ISO Standard issued in 2011. The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, relea…

I guess you're right. I still am wary about depending on this given the current conversation about ABI evolution with C++. And given that lots of languages can interop with C I think building C interfaces between binaries buys options

Re: Rust and C++ Interoperability in Chrome

#150

Post by emmelaich »

kbenson wrote: post #126
emmelaich wrote: post #110

Earlier quoted context omitted.

The Rust definition of 'unsafe' is very far from the everyday meaning. Yeah you can mentally substitute 'rustc_cannot_vouch_for' but why can't Rust use a word closer in meaning to that in the first place? We tend to misuse everyday meanings I think. I reminded of 1. the msdos warning that 'this program has used an illegal instruction and will be shut down' 2. That DNS names with underscore are 'illegal'. This one cau…

> The Rust definition of 'unsafe' is very far from the everyday meaning. "safe" is entirely relative in it's everyday meaning. To one person skydiving is safe, to another it is extremely unsafe. When you're a child your parent will tell you what is safe or not, but what your parent considers safe is based on their personal definition of safety. The rust language will tell you if what you've done is safe based on its…

I'd suggest that 'unsafe' is quite far away from the opposite meaning of 'safe' in everyday language.
Post reply on HN