3 ms·

Looking at this [0] news from about a month ago, the Chrome team showed that they are trying to bring Rust to the table. However, their wording was: > The Chro

by nikeee 4y ago

Looking at this [0] news from about a month ago, the Chrome team showed that they are trying to bring Rust to the table. However, their wording was: > The Chrome security team is working to make a cross-platform memory safe language available to Chromium developers. This document describes how to use that language in Chromium. The language, at least for now, is Rust. Could this mean that the "at least for now" part might hint to the language discussed in this thread? Memory safety seems to be a core goal of Carbon [1]: > Safer fundamentals, and an incremental path towards a memory-safe subset This approach could make sense, looking at their large C++ code base in Chrome. [0]: https://news.ycombinator.com/item?id=31830020 https://news.ycombinator.com/item?id=31830020 [1]: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang

tialaramex 4y ago
Sure, the Chrome security team have got a problem, Rust has a solution, if somebody comes along with a better solution why wouldn't you. But, right now Carbon doesn't have a better solution, it only has an ambition to build an incremental path toward being able to be a solution. Importantly it has an ambition but it has no proposal for how to get there. There are other safe languages, but AFAIK none of them launched with "Eh, we'll do safety later, I'm sure we don't need to start with it". The ones I'm thinking of all began with their safety principles and then they added cool features which were inspired by those principles. I reckon that even if that's not directly causal, it means the culture associated with these "We'll do safety later" languages doesn't prioritise safety highly enough. So ambition or not, they aren't going to put the hard work in to make it actually happen.
- pkasting 4y ago
  I work on the Chrome team. Safety is not the only goal for the codebase. There's also things like readability, maintainability, performance, and correctness. Finally, there's the need to chart a course towards how you get there. Rust provides many of these, but not much of an incremental path there. Carbon aims to provide many of these, but not as much safety as Rust (likely, even in the future). The upshot: there are tradeoffs, and we'll need to watch our options and make continual decisions as to the best courses of action. Such courses may differ by area of the project; it's possible we might choose to write some hardened services in Rust communicating via Mojo with mixed C++/Carbon code.
  - zozbot234 4y ago
    It's a web browser. If safety is not the one overarching concern when developing a web browser, of all things, the Chrome dev team is clearly dropping the ball. > Rust provides many of these, but not much of an incremental path there The incremental path is provided since you can refactor stuff into Rust at a scale as tiny as individual functions. Even an "unidiomatic", C/C++-like interface to "unidiomatic" unsafe Rust code is better than the status quo where no safe subset of the language can possibly exist. The Rust borrow checking approach does a very good job of establishing memory safety in a way that respects compositionality and module boundaries; most proposed alternatives do not engage with this obvious concern at all. Pre-"Modern" C/C++ idioms are inherently unviable because proving them safe is a global, program-wide concern. The Core C++ Guidelines developers are quite aware of this, which is why Guidelines-compliant code is quite rusty already.
    - pkasting 4y ago
      You cannot refactor C++ to Rust at the individual function level without good Rust<->C++ interop. The Carbon docs go into this at a sufficient level of detail; TLDR, interop paths exist but are insufficient and are actively being researched (and Chrome devs are heavily involved in said research). And as to your initial comment, of course safety is important, but if you don't understand why things like maintainability and performance are _also_ critically important, then your opinion is not sufficiently well-informed.
      - hi_herbert 4y ago

by nikeee 4y ago

tialaramex 4y ago

Sure, the Chrome security team have got a problem, Rust has a solution, if somebody comes along with a better solution why wouldn't you. But, right now Carbon doesn't have a better solution, it only has an ambition to build an incremental path toward being able to be a solution. Importantly it has an ambition but it has no proposal for how to get there. There are other safe languages, but AFAIK none of them launched with "Eh, we'll do safety later, I'm sure we don't need to start with it". The ones I'm thinking of all began with their safety principles and then they added cool features which were inspired by those principles. I reckon that even if that's not directly causal, it means the culture associated with these "We'll do safety later" languages doesn't prioritise safety highly enough. So ambition or not, they aren't going to put the hard work in to make it actually happen.

pkasting 4y ago
I work on the Chrome team. Safety is not the only goal for the codebase. There's also things like readability, maintainability, performance, and correctness. Finally, there's the need to chart a course towards how you get there. Rust provides many of these, but not much of an incremental path there. Carbon aims to provide many of these, but not as much safety as Rust (likely, even in the future). The upshot: there are tradeoffs, and we'll need to watch our options and make continual decisions as to the best courses of action. Such courses may differ by area of the project; it's possible we might choose to write some hardened services in Rust communicating via Mojo with mixed C++/Carbon code.
- zozbot234 4y ago
  It's a web browser. If safety is not the one overarching concern when developing a web browser, of all things, the Chrome dev team is clearly dropping the ball. > Rust provides many of these, but not much of an incremental path there The incremental path is provided since you can refactor stuff into Rust at a scale as tiny as individual functions. Even an "unidiomatic", C/C++-like interface to "unidiomatic" unsafe Rust code is better than the status quo where no safe subset of the language can possibly exist. The Rust borrow checking approach does a very good job of establishing memory safety in a way that respects compositionality and module boundaries; most proposed alternatives do not engage with this obvious concern at all. Pre-"Modern" C/C++ idioms are inherently unviable because proving them safe is a global, program-wide concern. The Core C++ Guidelines developers are quite aware of this, which is why Guidelines-compliant code is quite rusty already.
  - pkasting 4y ago
    You cannot refactor C++ to Rust at the individual function level without good Rust<->C++ interop. The Carbon docs go into this at a sufficient level of detail; TLDR, interop paths exist but are insufficient and are actively being researched (and Chrome devs are heavily involved in said research). And as to your initial comment, of course safety is important, but if you don't understand why things like maintainability and performance are _also_ critically important, then your opinion is not sufficiently well-informed.
    - hi_herbert 4y ago