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

131–140 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#131

Post by jcelerier »

mkoubaa wrote: post #65
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

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

Re: Rust and C++ Interoperability in Chrome

#132

Post by tolbish »

da39a3ee wrote: post #71

Question about the organizational context here. My understanding is that Chromium is an open source project. In practice though, when the document says "we" is it talking about mostly Google engineers? I read the document as indicating that there's a serious possibility of more widespread Rust usage, especially that last sentence If we become convinced this sort of interoperability is possible, we’ll revisit widespre…

There are Googlers in this thread considering it.

Re: Rust and C++ Interoperability in Chrome

#133

Post by ComputerGuru »

kbenson wrote: post #108
mths wrote: post #105

Earlier quoted context omitted.

> 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. Isn't that what they did? Through the use of https://github.com/dtolnay/cxx Agreed the article expressed the concern in a rather clumsy manner, but they seem to have a point for…

Yeah, in the end, they're taking a somewhat sane approach, it's just rather odd that they identify this as item number 1 that needs addressing. I'm not sure whether it's actually better to abstract all the unsafe away, or force it to shown where it's used. In one respect, they may be right, it might lesson the impact of unsafe and it gets used more freely. On the other, it also means that it's not necessarily immedia…

I disagree, you can automatically expose any unsafe function with a wrapper _safe function that does nothing more than call the former (possibly also wrapping fundamentally unsafe types in arguments and return values) which makes it appear safe but that doesn’t make it sane.

There would need to be domain understanding baked into each wrapper and some contract about what is happening on the other side of the ffi wall for it to qualify as both safe and sane, and I’m not sure their approach meets that high burden.

Re: Rust and C++ Interoperability in Chrome

#134

Post by ComputerGuru »

luizfelberti wrote: post #14
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.

> 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…

> Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways)

Reminds me of some of stringification abused in the Linux kernel. What looks like a function call passing the literal text param1## as an argument, where it would then trigger a different stringification in a subsequent preprocessor pass that prepended ##foo to the passed argument.

Re: Rust and C++ Interoperability in Chrome

#135

Post by ComputerGuru »

staticassertion wrote: post #119
Rochus wrote: post #6

So building Chromium becomes even more complex. Understanding the build system alone is a major achievement; I even had to build a tool for that: https://github.com/rochus-keller/gntools/ . Unfortunately that's only half of the rent; it also needs hundereds of Python scripts; and now also crates will be added.

The post is how they are not using rust , how could you possibly have come to the conclusion that the builds are going to get more complicated?

Because they’re clearly interested in possibly doing so in the future?

Re: Rust and C++ Interoperability in Chrome

#136

Post by ComputerGuru »

hoseja wrote: post #129

TIL Rust doesn't have function overloading. But actually not sure whether this is a good or bad thing.

I’ve been using it since pre 1.0 and I couldn’t tell you either. (Traits get you most of the way there but you’d see them exist for no other purpose which is just boilerplate imho.)

Re: Rust and C++ Interoperability in Chrome

#137

Post by M2Ys4U »

fgdfgddfg wrote: post #106
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?!

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.

Re: Rust and C++ Interoperability in Chrome

#138

Post by Const-me »

rightbyte wrote: post #57
qppo wrote: post #29

Earlier quoted context omitted.

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

Long time ago when computers were 32-bit I used to write something like this in C++:

    inline double pi()
    {
        __asm fldpi;
    }
On old enough compilers, this will get you 80-bit version of pi, more precision than even double. Completely useless now, modern compilers no longer emit x87 code.

Re: Rust and C++ Interoperability in Chrome

#139

Post by tracker1 »

emmelaich wrote: post #110
kbenson wrote: post #70

> 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…

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…

On a very similar note, a line in Mythbusters' opening that always amused me, "We're professionals, and that keeps us safe." No, it doesn't, it only means that someone is willing to pay you to do it.

I think the use of "unsafe" is exactly what is a common case. That is declaring, "I know what I am doing," and that for most people do do this may be a bad idea.

Re: Rust and C++ Interoperability in Chrome

#140

Post by xxpor »

Paul-ish wrote: post #100
xxpor wrote: post #28

Earlier quoted context omitted.

>if you have a heap allocated thing that is passed between Rust and C++, who frees it? Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.

Inside both Rust and C++ there are very well developed tools (eg smart pointers) for dealing with memory allocations. These tools were never written to be compatible with each other, so you lose them at the language boundary.

That makes sense. I do 99% C, so any time I even have to think about C++ it unfortunately turns into C with classes rather than C++, so I'm really not as familiar with the smart pointer options.
Post reply on HN