6 ms·

Yeah they've been evaluating it for years, and then I read that document and it frankly felt like a poison pill. Reading that document it sounds very much like

Yeah they've been evaluating it for years, and then I read that document and it frankly felt like a poison pill. Reading that document it sounds very much like it's "how do we keep writing C++ while addressing the growing interest in rust".

olliej 5y ago
No, the problem here is very real - rust doesn't have a reasonable c++ interop story, which means you have to rewrite potentially very large amounts of code at once and hope you don't regress anything. At the same time you have to continue normal development work, which is necessarily still C++, because again, you can't adopt rust in small sections. Basically to rewrite one DOM feature in rust would have a high likelihood of requiring rewriting the entire DOM implementation in rust, which would also require rearchitecting. While doing that other people would be wanting to continue working, but they don't have a rust build to work on so they have to continue in c++, thus sadness and conflicts. The other solution is to implement features in rust, and use a c++ wrapper to interface with that rust implementation, but now you've lost the memory safety advantages of rust (most of which are lifetime related, not bounds checking), and the C++ interface itself could be exciting as it could end up having to marshal other types.
- staticassertion 5y ago
  Replacing small components like a single codec or parser wouldn't require anywhere near what Google is asking for in that document. I'm not saying to replace V8 with Rust. > but now you've lost the memory safety advantages of rust No you haven't.
  - jsnell 5y ago
    But replacing small isolated components is not a very interesting option. It means you're paying the costs of a multi-language codebase, in terms of build complexity, having to duplicate infrastructure, and siloing of developers. In return you'll only be getting limited benefits from it, since the usage will only be restricted to few cases and a full migration can never happen. Every single decision on what language to use for a component in becomes a hard to reverse ("will this component always remain a leaf node with a really simple interface?"), slowing down decision making and ossifying the architecture.
    - staticassertion 5y ago
      > But replacing small isolated components is not a very interesting option. I seriously disagree. Again, I mentioned things like JSON parsing which deal with untrusted data but also are too performance sensitive to move OOP. Chromium's own security guidelines explicitly states that you should never mix memory unsafe code with inprocess code with untrusted input. I strongly believe you'd get significant returns by incrementally replacing components like that with Rust. > Every single decision on what language to use for a component in becomes a hard to reverse This is purely an organizational issue in my opinion. If the decision were made to follow the guidelines their security team has laid out, there is no question or slow-down. The guidelines are very competent and clear; memory unsafe, untrusted input, in-process - pick one at most.
      - esprehn 5y ago
        Do you have examples of exploits in the non-sandboxed JSON parser? That code doesn't appear to have any security/memory safety related fixes in the last 2 years: https://chromium.googlesource.com/chromium/src.git/+log/refs/heads/main/base/json https://chromium.googlesource.com/chromium/src.git/+log/refs... It's not clear what the return would be from rewriting that code in rust.
        staticassertion 5y ago
        JSON is just a straightforward example because it's easy to understand how it falls into Chromium's threat model. Feel free to replace it with font parsing, audio/video codecs, etc, and you'll find thousands of relevant vulns.
    - pcwalton 5y ago
      Being able to add new features without greatly expanding the attack surface is important for security. When new components of Firefox have been written in Rust, there have empirically been far fewer security problems to shake out than when they've been written in C++. Is Rust of more limited benefit when it's only being used for certain components as opposed to the entire codebase? Sure. But is it still worth using for new code? Frequently, yes.
- pcwalton 5y ago
  > No, the problem here is very real - rust doesn't have a reasonable c++ interop story, which means you have to rewrite potentially very large amounts of code at once and hope you don't regress anything. At the same time you have to continue normal development work, which is necessarily still C++, because again, you can't adopt rust in small sections. This was a somewhat more accurate summary a few years ago (though saying "you can't adopt rust in small sections" ignores the fact that Firefox among others did just that), but the cxx crate has made huge strides lately, and it's much more feasible now to interoperate at a deep level between Rust and C++. (In fact, dealing with this interoperability constitutes a large part of my job nowadays, and thanks to cxx it performs swimmingly.) We're even starting to talk about advanced features like seamless C++ async/await support in cxx.
  - haberman 5y ago
    Can Rust instantiate a C++ template? How do you interop across interfaces that use templates?
    - pcwalton 5y ago
      Yes! The tutorial for cxx shows how you can use common templated types like std::vector: https://cxx.rs/index.html https://cxx.rs/index.html More details are in the crate documentation: https://docs.rs/cxx/1.0.49/cxx/ https://docs.rs/cxx/1.0.49/cxx/ Note that the philosophy of cxx isn't to support all of C++'s semantics (templates make this impossible in the limit as Rust has no SFINAE rule for example), but rather to support the important use cases that arise in practice. It's also worth noting that, these days, bindgen has support for instantiating C++ templates, though it operates at a much lower level. Compared to cxx, bindgen is oriented more toward being comprehensive than being easy.
      - vlovich123 5y ago
        Have you gotten a chance to use cxx in a large “production” “legacy” c++ codebase? It’s great but there’s quite a few roadblocks that I encountered even trying something I would have considered that should be “easy”. I could easily imagine that Chromium would have an even tougher time. Some highlights: * if you’re not careful, you’ll end up with linkage issues if you link in multiple crates. This means 1 uber create that has all your Rust dependencies. This can mess with parallelism in your build since Cargo isn’t coordinating with the broader system. * speaking of build systems, chromium probably wouldn’t use create meaning extra build system integration, especially since they don’t use Bazel/Blaze. * cxx still can’t pass across certain types (Arc and Option being the big ones) and is missing a general story for extending it with custom types. * cxx can frequently cause you to have to reach to unsafe anyway because the lifetime semantics you want to express cannot be done in pure Rust because the other half lives in c++. Don’t get me wrong. Rust is fantastic and a joy to use. Dismissing the challenges a project like Chromium has as “they just want to stick to c++” isn’t a fair look at the situation. Lots of smart people work on these projects and are keenly aware of Rust. Additionally managers and executives are keenly aware of the security benefits so there’s definitely downward pressure to try to adopt these (and large efforts spent investigating how to enable this whole maintaining developer velocity).

olliej 5y ago

No, the problem here is very real - rust doesn't have a reasonable c++ interop story, which means you have to rewrite potentially very large amounts of code at once and hope you don't regress anything. At the same time you have to continue normal development work, which is necessarily still C++, because again, you can't adopt rust in small sections. Basically to rewrite one DOM feature in rust would have a high likelihood of requiring rewriting the entire DOM implementation in rust, which would also require rearchitecting. While doing that other people would be wanting to continue working, but they don't have a rust build to work on so they have to continue in c++, thus sadness and conflicts. The other solution is to implement features in rust, and use a c++ wrapper to interface with that rust implementation, but now you've lost the memory safety advantages of rust (most of which are lifetime related, not bounds checking), and the C++ interface itself could be exciting as it could end up having to marshal other types.

staticassertion 5y ago
Replacing small components like a single codec or parser wouldn't require anywhere near what Google is asking for in that document. I'm not saying to replace V8 with Rust. > but now you've lost the memory safety advantages of rust No you haven't.
- jsnell 5y ago
  But replacing small isolated components is not a very interesting option. It means you're paying the costs of a multi-language codebase, in terms of build complexity, having to duplicate infrastructure, and siloing of developers. In return you'll only be getting limited benefits from it, since the usage will only be restricted to few cases and a full migration can never happen. Every single decision on what language to use for a component in becomes a hard to reverse ("will this component always remain a leaf node with a really simple interface?"), slowing down decision making and ossifying the architecture.
  - staticassertion 5y ago
    > But replacing small isolated components is not a very interesting option. I seriously disagree. Again, I mentioned things like JSON parsing which deal with untrusted data but also are too performance sensitive to move OOP. Chromium's own security guidelines explicitly states that you should never mix memory unsafe code with inprocess code with untrusted input. I strongly believe you'd get significant returns by incrementally replacing components like that with Rust. > Every single decision on what language to use for a component in becomes a hard to reverse This is purely an organizational issue in my opinion. If the decision were made to follow the guidelines their security team has laid out, there is no question or slow-down. The guidelines are very competent and clear; memory unsafe, untrusted input, in-process - pick one at most.
    - esprehn 5y ago
      Do you have examples of exploits in the non-sandboxed JSON parser? That code doesn't appear to have any security/memory safety related fixes in the last 2 years: https://chromium.googlesource.com/chromium/src.git/+log/refs/heads/main/base/json https://chromium.googlesource.com/chromium/src.git/+log/refs... It's not clear what the return would be from rewriting that code in rust.
      - staticassertion 5y ago
        JSON is just a straightforward example because it's easy to understand how it falls into Chromium's threat model. Feel free to replace it with font parsing, audio/video codecs, etc, and you'll find thousands of relevant vulns.
  - pcwalton 5y ago
    Being able to add new features without greatly expanding the attack surface is important for security. When new components of Firefox have been written in Rust, there have empirically been far fewer security problems to shake out than when they've been written in C++. Is Rust of more limited benefit when it's only being used for certain components as opposed to the entire codebase? Sure. But is it still worth using for new code? Frequently, yes.
pcwalton 5y ago
> No, the problem here is very real - rust doesn't have a reasonable c++ interop story, which means you have to rewrite potentially very large amounts of code at once and hope you don't regress anything. At the same time you have to continue normal development work, which is necessarily still C++, because again, you can't adopt rust in small sections. This was a somewhat more accurate summary a few years ago (though saying "you can't adopt rust in small sections" ignores the fact that Firefox among others did just that), but the cxx crate has made huge strides lately, and it's much more feasible now to interoperate at a deep level between Rust and C++. (In fact, dealing with this interoperability constitutes a large part of my job nowadays, and thanks to cxx it performs swimmingly.) We're even starting to talk about advanced features like seamless C++ async/await support in cxx.
- haberman 5y ago
  Can Rust instantiate a C++ template? How do you interop across interfaces that use templates?
  - pcwalton 5y ago
    Yes! The tutorial for cxx shows how you can use common templated types like std::vector: https://cxx.rs/index.html https://cxx.rs/index.html More details are in the crate documentation: https://docs.rs/cxx/1.0.49/cxx/ https://docs.rs/cxx/1.0.49/cxx/ Note that the philosophy of cxx isn't to support all of C++'s semantics (templates make this impossible in the limit as Rust has no SFINAE rule for example), but rather to support the important use cases that arise in practice. It's also worth noting that, these days, bindgen has support for instantiating C++ templates, though it operates at a much lower level. Compared to cxx, bindgen is oriented more toward being comprehensive than being easy.
    - vlovich123 5y ago
      Have you gotten a chance to use cxx in a large “production” “legacy” c++ codebase? It’s great but there’s quite a few roadblocks that I encountered even trying something I would have considered that should be “easy”. I could easily imagine that Chromium would have an even tougher time. Some highlights: * if you’re not careful, you’ll end up with linkage issues if you link in multiple crates. This means 1 uber create that has all your Rust dependencies. This can mess with parallelism in your build since Cargo isn’t coordinating with the broader system. * speaking of build systems, chromium probably wouldn’t use create meaning extra build system integration, especially since they don’t use Bazel/Blaze. * cxx still can’t pass across certain types (Arc and Option being the big ones) and is missing a general story for extending it with custom types. * cxx can frequently cause you to have to reach to unsafe anyway because the lifetime semantics you want to express cannot be done in pure Rust because the other half lives in c++. Don’t get me wrong. Rust is fantastic and a joy to use. Dismissing the challenges a project like Chromium has as “they just want to stick to c++” isn’t a fair look at the situation. Lots of smart people work on these projects and are keenly aware of Rust. Additionally managers and executives are keenly aware of the security benefits so there’s definitely downward pressure to try to adopt these (and large efforts spent investigating how to enable this whole maintaining developer velocity).