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

101–110 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#101

Post by Const-me »

kazagistar wrote: post #67
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.

Here's a quote from the article:

> We think the hardest part of this is imagining a safe way to pass types between Rust and C++. That requires auto-generated shim code on both the Rust and C++ side.

I'll be very surprised if they'll be able to make a production-quality solution. The languages are just too different, and Rust's OOP support is one of these issues.

Re: Rust and C++ Interoperability in Chrome

#102

Post by ncmncm »

This is all very clever, but it has certain really, really fundamental problems.

1. The main program will remain C++ (or anyway Google's hobbled subset). New code you choose to get done in Rust will be lower-level code, implementing specific new features, or re-implementing low-level stuff too toxic to fix. So, the main task is not Rust calling into C++ code, but C++ calling Rust. That doesn't mean the Rust code won't ever need to call out to utility code, but: You are coding in Rust for an actual, you know, reason, right? Maybe that utility stuff should be RIIR, first? Otherwise what was the point, again?

2. It is all very well to talk about Rust calling C-like functions and virtual functions, but that only takes us up to 1985. We all know (I hope) that the overwhelming majority of useful power in C++ code is in features wholly inaccessible to Rust, even in principle. How will Rust do overload resolution? Inlines? (Also 1985.) Template instantiation? Exception handling? (That takes us to 1992.) Template function overloading and partial specialization? (1998). I could go on, right up to 2020.

There are other fundamental problems, but this seems like enough for now. No sense piling on. At least point 1 makes point 2 less a problem.

Re: Rust and C++ Interoperability in Chrome

#103

Post by est31 »

foota wrote: post #98
est31 wrote: post #80

Earlier quoted context omitted.

Rust unsafe doesn't mean "does something sketchy". It means "compiler I know what I'm doing". It's equivalent to casting raw C pointers. You are supposed to know what you are doing when doing that, but you will be on your own. It might still be perfectly safe, but the compiler can't tell.

Sure, but it does indicate something likely to be wrong, relative to normal rust code. If every C++ function is unsafe then it becomes less clear where the actually unsafe rust bits are.

C++ has made it very painless to upgrade from C, by being (mostly) a superset. It's so painless that many codebases haven't really upgraded and it's common to see C-isms sprinkled around larger code bases. Some classes written decades ago can survive the years written in horrible outdated style. For some that might be a feature, but for the quality (or safety) of the code it isn't.

Yes, when there is too much unsafe in a Rust codebase then the unsafe label inflates and the safety guarantees aren't as good. But the conclusion of that shouldn't involve changing definitions of what's unsafe and what isn't, but using less unsafe overall.

Rust can interface with C++, but it isn't well suited for too intimate interfacing. That's not where its strengths lie.

Re: Rust and C++ Interoperability in Chrome

#104

Post by Snelius »

webkike wrote: post #62
Matthias247 wrote: post #46

Earlier quoted context omitted.

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

You will lost his (*_ptr) magic cuz types match is not compatible. Mem must be free on the allocation side, kind of law.

Re: Rust and C++ Interoperability in Chrome

#105

Post by mths »

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…

> 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 their particular use case, and they addressed it appropriately.

Re: Rust and C++ Interoperability in Chrome

#106

Post by fgdfgddfg »

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

Re: Rust and C++ Interoperability in Chrome

#108

Post by kbenson »

mths wrote: post #105
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…

> 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 immediately obvious when you're crossing boundaries, since the obvious bits and intentionally hidden away.

Though I'll freely admit my initial responses were a bit hyperbolic and... testy. :)

Re: Rust and C++ Interoperability in Chrome

#109

Post by Impossible »

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…

Yeah... The unsafe keyword is not unique to Rust either and exist in C# with similar semantics (although slightly different due to gc vs borrow checker memory management). One way to think of it is unsafe blocks effectively let you write C, with pointers and other memory unsafe operations inside of an otherwise safe language. This can be used for performance critical code (in a similar, but higher level, way as inline asm) but is primarily used to interface with unsafe C APIs (OS APIs, graphics APIs, etc) and libraries. Entirely agree that this is a misunderstanding.

Re: Rust and C++ Interoperability in Chrome

#110

Post by emmelaich »

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 caused an amusing kerfuffle at one company I worked at.

3. That certain crypto algos are 'broken'

Post reply on HN