5 ms·

> Honestly, I am extremely glad that Google is finally leaving the ecosystem, as I generally do not enjoy it when Google engineers try to force their ridiculous

> Honestly, I am extremely glad that Google is finally leaving the ecosystem, as I generally do not enjoy it when Google engineers try to force their ridiculous use cases down peoples' throats, as they seem to believe they simply know better than everyone else how to develop software. Well, you may be celebrating a bit prematurely then. Google still has a ton of C++ and they haven't stopped writing it. It's going to take ~forever until Google has left the C++ ecosystem. What did happen was that Google majorly scaled down their efforts in the committee. When it comes to the current schism on how to improve the safety of C++ there are largely two factions: * The Bjarne/Herb [1] side that focuses on minimal changes to the code. The idea here is to add different profiles to the language and then [draw the rest of the fucking owl]. The big issue here is that it's entirely unclear on how they will achieve temporal and spatial memory safety. * The other side is represented by Sean Baxter and his work on Safe C++. This is basically a whole-sale adoption of Rust's semantics. The big issue here is that it's effectively introducing a new language that isn't C++. Google decided to pursue Carbon and isn't a major playing in either of the above efforts. Last time I checked, that language is not not meant to be memory safe. [1] https://github.com/BjarneStroustrup/profiles https://github.com/BjarneStroustrup/profiles [2] https://safecpp.org/draft.html https://safecpp.org/draft.html

pjmlp 2y ago
People like to always talk about Carbon like that, yet the team is the first to point out anyone that can use something else, should. Carbon is an experiment, that they aren't sure how it is going to work out in first place. > "If you can use Rust, ignore Carbon" https://github.com/carbon-language/carbon-lang/blob/e09bf82d364d8efb70edb55213b31d7260d8fe4f/docs/project/faq.md#if-you-can-use-rust-ignore-carbon https://github.com/carbon-language/carbon-lang/blob/e09bf82d... > "We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and communit" https://github.com/carbon-language/carbon-lang/blob/e09bf82d364d8efb70edb55213b31d7260d8fe4f/README.md#project-status https://github.com/carbon-language/carbon-lang/blob/e09bf82d...
IAmLiterallyAB 2y ago
> Herb side that proposes minimal changes Herb is developing a whole second syntax, I wouldn't call that minimal changes. And probably the only way to evolve the language at this point, because like you said Sean is introducing a different language entirely, so its not C++ at that point. I really like some of Herb's ideas,but it seems less and less likely they'll ever be added to C++
- darknavi 2y ago
  Have you seen some of his recent talks? Lots of underpinnings of cppfront have been added or are in committy. He compares it to the JS/TS relationship.
  - chipdart 2y ago
    > He compares it to the JS/TS relationship. OP is right, TypeScript is a whole new syntax, and it's shtick is that it can be transpiled into JavaScript.
  - nox101 2y ago
    It's not really a valid comparison though. cppfront is a different language that just happens to be compatible with C++. ts/js is were ts is just js with types. You can comment out the types and it just runs. cppfront's language you'll actually have to re-write the code to get it to compile in C++ typescript function add(a: number, b: number): number { return a + b }; javascript function add(a/*: number*/, b/*: number*/)/*: number*/ { return a + b }; cppfront add: (a: float, b: float): float = { a + b; } cpp float add(float a, float b) { return a + b; }
    - HelloNurse 2y ago
      Do you realize that the Typescript example contains strictly more information than the Javascript one (namely, declarations for the type of three things) and is therefore more complex to compile, while the two C++ examples are semantically identical (the last expression in the function is returned implicitly without having to write "return") and the new syntax is easier to parse?
Conscat 2y ago
Carbon isn't currently memory safe, but Chandler Carruth has made it clear that every security expert he talked to says the same thing: memory safety is a requirement for security. He at least claims that Carbon will have memory safety features such as borrow checking down the line. I guess we'll see.
- vlovich123 2y ago
  It’s worrying to me that Carbon separates data races and memory safety as two distinct things when data races can easily cause both spatial and temporal memory safety issues. Similarly, type safety, can also cause spatial issues (e.g. many kernel exploits in Darwin were a result of causing type confusion for the SLAB allocator resulting in an exploitable memory safety issue). The entire philosophy errs too much in the direction of “being reasonable” and “pragmatic” while getting fundamental things wrong. > Over time, safety should evolve using a hybrid compile-time and runtime safety approach to eventually provide a similar level of safety to a language that puts more emphasis on guaranteed safety, such as Rust. However, while Carbon may encourage developers to modify code in support of more efficient safety checks, it will remain important to improve the safety of code for developers who cannot invest into safety-specific code modifications. That’s really just paying lip service to Rust without recognizing that the key insight is that optional memory safety isn’t memory safety. It is kind of neat just how much Rust has managed to disrupt the C++ ecosystem and dislodge its position.
  - gpderetta 2y ago
    In principle data races can cause memory safety issues, but they are usually very hard to exploit. Java guarantees VM integrity in the face of data races, while for example many races are UB in theory and in practice in Go. Both are considered safe languages. Sometimes pragmatism is in fact a valid goal. edit: from a practical point of view I don't know how realistic is to retrofit memory safety to a language that lacks it.
    - zozbot234 2y ago
      Golang is very much not considered "safe" from data races.
josh11b 2y ago
(Carbon lang dev here.) Carbon is intended to be memory safe! (Not sure whether you intended to write a double negative there.) There are a few reasons that might not be clear: * Carbon has relatively few people working on it. We currently are prioritizing work on the compiler at the moment, and don't yet have the bandwidth to also work on the safety design. * As part of our migration-from-C++ story, where we expect code to transition C++ -> unsafe Carbon -> safe Carbon, we plan on supporting unsafe Carbon code with reasonable ergonomics. * Carbon's original focus was on evolvability, and didn't focus on safety specifically. Since then it has become clear that memory safety is a requirement for Carbon's success, and will be our first test of those evolvability goals. Talks like https://www.youtube.com/watch?v=1ZTJ9omXOQ0 https://www.youtube.com/watch?v=1ZTJ9omXOQ0 better reflect more recent plans around this topic.
- vinkelhake 2y ago
  Thanks for the correction, I appreciate it! The double negative was not intended :)
- bcoates 2y ago
  Not super familiar with Carbon but .. what's the elevator pitch for porting my C++ to unsafe Carbon? Can it be done with an automated refactoring tool or something? I feel like if I'm gonna go through the whole nightmare of a code port I should get something for it as opposed to just relying on interop
  - bitexploder 2y ago
    The idea is that it is an incremental process. By default you should be able to make minimal changes to your code and it should mostly just work. Over time you can use features that more tightly couple you to Carbon, such as memory safety. Google's motivation is supporting its massive C++ codebase while providing a path for memory safety and other features. If your use case does not closely mirror that of Google's, namely, that you have 10+ year old code you intend, and have, to maintain, Carbon probably doesn't make sense for you and that is generally made pretty clear for anyone interested in the language.

pjmlp 2y ago

People like to always talk about Carbon like that, yet the team is the first to point out anyone that can use something else, should. Carbon is an experiment, that they aren't sure how it is going to work out in first place. > "If you can use Rust, ignore Carbon" https://github.com/carbon-language/carbon-lang/blob/e09bf82d364d8efb70edb55213b31d7260d8fe4f/docs/project/faq.md#if-you-can-use-rust-ignore-carbon https://github.com/carbon-language/carbon-lang/blob/e09bf82d... > "We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and communit" https://github.com/carbon-language/carbon-lang/blob/e09bf82d364d8efb70edb55213b31d7260d8fe4f/README.md#project-status https://github.com/carbon-language/carbon-lang/blob/e09bf82d...

IAmLiterallyAB 2y ago

> Herb side that proposes minimal changes Herb is developing a whole second syntax, I wouldn't call that minimal changes. And probably the only way to evolve the language at this point, because like you said Sean is introducing a different language entirely, so its not C++ at that point. I really like some of Herb's ideas,but it seems less and less likely they'll ever be added to C++

darknavi 2y ago
Have you seen some of his recent talks? Lots of underpinnings of cppfront have been added or are in committy. He compares it to the JS/TS relationship.
- chipdart 2y ago
  > He compares it to the JS/TS relationship. OP is right, TypeScript is a whole new syntax, and it's shtick is that it can be transpiled into JavaScript.
- nox101 2y ago
  It's not really a valid comparison though. cppfront is a different language that just happens to be compatible with C++. ts/js is were ts is just js with types. You can comment out the types and it just runs. cppfront's language you'll actually have to re-write the code to get it to compile in C++ typescript function add(a: number, b: number): number { return a + b }; javascript function add(a/*: number*/, b/*: number*/)/*: number*/ { return a + b }; cppfront add: (a: float, b: float): float = { a + b; } cpp float add(float a, float b) { return a + b; }
  - HelloNurse 2y ago
    Do you realize that the Typescript example contains strictly more information than the Javascript one (namely, declarations for the type of three things) and is therefore more complex to compile, while the two C++ examples are semantically identical (the last expression in the function is returned implicitly without having to write "return") and the new syntax is easier to parse?

Conscat 2y ago

Carbon isn't currently memory safe, but Chandler Carruth has made it clear that every security expert he talked to says the same thing: memory safety is a requirement for security. He at least claims that Carbon will have memory safety features such as borrow checking down the line. I guess we'll see.

vlovich123 2y ago
It’s worrying to me that Carbon separates data races and memory safety as two distinct things when data races can easily cause both spatial and temporal memory safety issues. Similarly, type safety, can also cause spatial issues (e.g. many kernel exploits in Darwin were a result of causing type confusion for the SLAB allocator resulting in an exploitable memory safety issue). The entire philosophy errs too much in the direction of “being reasonable” and “pragmatic” while getting fundamental things wrong. > Over time, safety should evolve using a hybrid compile-time and runtime safety approach to eventually provide a similar level of safety to a language that puts more emphasis on guaranteed safety, such as Rust. However, while Carbon may encourage developers to modify code in support of more efficient safety checks, it will remain important to improve the safety of code for developers who cannot invest into safety-specific code modifications. That’s really just paying lip service to Rust without recognizing that the key insight is that optional memory safety isn’t memory safety. It is kind of neat just how much Rust has managed to disrupt the C++ ecosystem and dislodge its position.
- gpderetta 2y ago
  In principle data races can cause memory safety issues, but they are usually very hard to exploit. Java guarantees VM integrity in the face of data races, while for example many races are UB in theory and in practice in Go. Both are considered safe languages. Sometimes pragmatism is in fact a valid goal. edit: from a practical point of view I don't know how realistic is to retrofit memory safety to a language that lacks it.
  - zozbot234 2y ago
    Golang is very much not considered "safe" from data races.

josh11b 2y ago

(Carbon lang dev here.) Carbon is intended to be memory safe! (Not sure whether you intended to write a double negative there.) There are a few reasons that might not be clear: * Carbon has relatively few people working on it. We currently are prioritizing work on the compiler at the moment, and don't yet have the bandwidth to also work on the safety design. * As part of our migration-from-C++ story, where we expect code to transition C++ -> unsafe Carbon -> safe Carbon, we plan on supporting unsafe Carbon code with reasonable ergonomics. * Carbon's original focus was on evolvability, and didn't focus on safety specifically. Since then it has become clear that memory safety is a requirement for Carbon's success, and will be our first test of those evolvability goals. Talks like https://www.youtube.com/watch?v=1ZTJ9omXOQ0 https://www.youtube.com/watch?v=1ZTJ9omXOQ0 better reflect more recent plans around this topic.

vinkelhake 2y ago
Thanks for the correction, I appreciate it! The double negative was not intended :)
bcoates 2y ago
Not super familiar with Carbon but .. what's the elevator pitch for porting my C++ to unsafe Carbon? Can it be done with an automated refactoring tool or something? I feel like if I'm gonna go through the whole nightmare of a code port I should get something for it as opposed to just relying on interop
- bitexploder 2y ago
  The idea is that it is an incremental process. By default you should be able to make minimal changes to your code and it should mostly just work. Over time you can use features that more tightly couple you to Carbon, such as memory safety. Google's motivation is supporting its massive C++ codebase while providing a path for memory safety and other features. If your use case does not closely mirror that of Google's, namely, that you have 10+ year old code you intend, and have, to maintain, Carbon probably doesn't make sense for you and that is generally made pretty clear for anyone interested in the language.