Rust and C++ Interoperability in Chrome • Hacker News Board

Re: Rust and C++ Interoperability in Chrome

#71

Post by da39a3ee » Wed, Aug 19, 2020, 9:54 PM UTC

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 widespread use of Rust in Chrome, and at that point we plan to work hard to achieve this with robust production-quality solutions.

Would it be wrong to take away from this that in some teams within Google, using Rust in places where C++ would have been used, is something that is being considered seriously?

Re: Rust and C++ Interoperability in Chrome

#72

Post by arcticbull » Wed, Aug 19, 2020, 9:58 PM UTC

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…

> ... known to be less safe than normal C++.

Oh... no, no, that's... very unsafe lol.

Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.

Re: Rust and C++ Interoperability in Chrome

#73

Post by erik_seaberg » Wed, Aug 19, 2020, 9:59 PM UTC

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?!

The strangler pattern (gradually replacing C++ with Rust) is pretty much the only alternative to a https://www.joelonsoftware.com/2000/04/06/things-you-should-... complete rewrite.

Re: Rust and C++ Interoperability in Chrome

#74

Post by kbenson » Wed, Aug 19, 2020, 10:04 PM UTC

arcticbull wrote: post #72

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…

> ... known to be less safe than normal C++. Oh... no, no, that's... very unsafe lol. Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.

> "unchecked" might be a better annotation come to think of it.

Yeah, it's come up before in discussions here. Depending on the context you're coming from/working in, unchecked either makes more sense, or less sense than unsafe. When working within Rust, unsafe makes sense, it maps to how people think about what they are doing, because rustc is checking everything. When working between Rust and other languages/libraries, it's a bit less accurate, and "unchecked" makes more sense.

Re: Rust and C++ Interoperability in Chrome

#75

Post by malkia » Wed, Aug 19, 2020, 10:06 PM UTC

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.

Fuchsia, uses also "gn" (then ninja) and has rust support too

Re: Rust and C++ Interoperability in Chrome

#76

Post by cmrdporcupine » Wed, Aug 19, 2020, 10:07 PM UTC

Hm, I'm a Googler working on the chromecast platform and a Chromium committer who thinks Rust Is Pretty Neat. I'll look internally as well, but who can I talk to about helping out with Rust adoption in the context of the chromium codebase?

Re: Rust and C++ Interoperability in Chrome

#77

Post by [deleted] » Wed, Aug 19, 2020, 10:16 PM UTC

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…

[deleted]

Re: Rust and C++ Interoperability in Chrome

#78

Post by est31 » Wed, Aug 19, 2020, 10:21 PM UTC

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?!

You have to start somewhere. Every C++ component that's replaced by a safe Rust component is a reduction in attack surface.

Re: Rust and C++ Interoperability in Chrome

#79

Post by nicoburns » Wed, Aug 19, 2020, 10:26 PM UTC

arcticbull wrote: post #72

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…

> ... known to be less safe than normal C++. Oh... no, no, that's... very unsafe lol. Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.

I don't think they're misunderstanding the meaning. I think there'a just so much "boilerplate unsafe" for such cases that it would distract from other uses which they could meaningfully audit.

Re: Rust and C++ Interoperability in Chrome

#80

Post by est31 » Wed, Aug 19, 2020, 10:29 PM UTC

foota wrote: post #45

lalaithion wrote: post #39

Earlier quoted context omitted.

I disagree; All of the things you say about C++ code also apply to unsafe Rust code. There's an unsafe keyword that allows using that unsafe code, and when you use it, you are asserting to the compiler that "I promise this code is actually being used in a safe way". All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being us…

I think the issue is that rust unsafe means "does something sketchy" whereas even perfectly safe C++ would have to be annotated unsafe.

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.