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

111–120 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#111

Post by ncmncm »

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

You must be talking about Microsoft stuff not applicable here.

Re: Rust and C++ Interoperability in Chrome

#112

Post by ncmncm »

ChrisSD wrote: post #22
jcranmer wrote: post #18

Earlier quoted context omitted.

It's also worth mentioning that Mozilla tends not to use a lot of standard C++ types, using nsTArray instead of std::vector or nsA?C?String instead of std::string. This makes the porting of APIs using arrays or structs easier, since Mozilla owns the ABI rather than needing to worry about different standard libraries having different ABIs.

C++ interop with C++ can be a pain. E.g. even with the same version of the same compiler, GCC can have different options enabled that affect the layout of some types.

That is the same in all languages mature enough to have variant options. Rust included.

Therefore, a tendentious distraction from the topic. Chris, I shall expect better from you in the future.

Re: Rust and C++ Interoperability in Chrome

#113

Post by asveikau »

qppo wrote: post #29
fullstop wrote: post #15

Earlier quoted context omitted.

I keep meaning to dive into Rust, but it feels like they've removed so many useful things in the name of safety. I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust. I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point…

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.

math.h has M_PI in posix.

Re: Rust and C++ Interoperability in Chrome

#114

Post by powersnail »

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…

I'm reminded of "my phone has 64g of memory". It makes sense to a lay person, that memory would mean storage.

This is inevitable. We either invent new words, or we use existing words from the natural language. The latter will always lead to confusion at some point, because the domain-specific concept doesn't exist in the rest of the world. To represent such a concept, a word would need to deviate from its everyday usage.

I think Rust's "unsafe" is an okay choice; the "vouching" is a feature about memory safety after all.

Re: Rust and C++ Interoperability in Chrome

#115

Post by patrick451 »

kbenson wrote: post #95
codeflo wrote: post #87

Earlier quoted context omitted.

The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. A lot of Rust’s std and library ecosystem provides safe wrappers around underlying unsafe C APIs, by cleverly using borrow semantics and performing additional runtime checks. The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is…

> The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe. Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it…

> That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology.

I'd say that Rust is using incorrect terminology, since it is at loggerheads with "the usual understanding" (which should be the default, not something "resorted to"). Rust could have chosen a different word than safe/un-safe, but they didn't.

Re: Rust and C++ Interoperability in Chrome

#116

Post by qppo »

asveikau wrote: post #113
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.

math.h has M_PI in posix.

The point is that using macros for constants is frowned upon in modern codebases, just like all other use cases for macros that break type safety and the one definition rule.

Re: Rust and C++ Interoperability in Chrome

#117

Post by Ericson2314 »

outworlder wrote: post #48
eggsnbacon1 wrote: post #10

Do they really need to access thousands of C++ API calls from Rust? Doesn't this defeat the purpose of writing safe code in Rust? This smells of "not invented here" which applies to Google projects pretty often. They should focus on integrating Rust in portions of the API instead of exposing a gigantic unsafe API surface, essentially making all their code unsafe. Unless the Chrome codebase is really such a mess that…

> Do they really need to access thousands of C++ API calls from Rust? Yes. It's turtles all the way down. Applying this line of thought to its logical conclusion, it wouldn't be worth it until we have written the OS itself and all firmware in Rust.

Just within the process. Between processes or process and kernel, there are already runtime checks, so Rust isn't contributing safety so much quality.

Re: Rust and C++ Interoperability in Chrome

#119

Post by staticassertion »

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?

Re: Rust and C++ Interoperability in Chrome

#120

Post by [deleted] »

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…

[deleted]
Post reply on HN