11–18 of 18 posts
I completely agree. "Rewrite it in Rust" is not the answer (it might be part of the answer).
After spending some time laying the groundwork, leadership at my employer is receptive to this idea. But now what? How do we transform our ecosystem? Anyone know of books, training, consultants worth paying?
Earlier quoted context omitted.
People might then discard the whole whitepaper as pushing Carbon, there are probably lots of other options that would be worthy of mention. Is Carbon an actual subset, because the syntax looks different to me in the Wikipedia page example? I'd love to see a list of candidates and how they compare.
Carbon is not a subset of C++, it will have a memory safe subset of itself, like Rust does. That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
>Best candidate for C++ is likely similar to Rust’s borrow checker
It is stated clearly in the talk that this is true for Carbon as well
[0] https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in...
[1] relevant timestamps:
Earlier quoted context omitted.
I really don't get where people get the "Carbon is production ready" vibe from.
I don't think they do, specifically, they just know it exists. I am probably one of the most likely people in the world to be tracking what Carbon is up to, yet I only really started paying attention last week. It's hard to keep up with many things.
Meanwhile, the last public talks were about building the frontend.
Earlier quoted context omitted.
Carbon is not a subset of C++, it will have a memory safe subset of itself, like Rust does. That said, Carbon’s definition of memory safety does not include data race safety, and so will not have a borrow checker.
Unless something has chnaged since this talk[0][1], I don't think that is accurate. >Best candidate for C++ is likely similar to Rust’s borrow checker It is stated clearly in the talk that this is true for Carbon as well [0] https://chandlerc.blog/slides/2023-cppnow-carbon-strategy/in... [1] relevant timestamps: https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h31m34s https://youtube.com/watch?v=1ZTJ9omXOQ0&t=1h9m49s
I will have to re-watch it, thank you.
I find the paper is really low on anything that other organizations relying on C++ heavily can take home as advice.
Like they still need their C++ systems [3]. They failed to make changes in their C++ systems that will make a difference [2]. And only progress they have is writing new peripheral or unimportant systems in other languages [1]. They do not believe that anything of importance will be following rewrite path on their side [3].
1. "gradual transition towards memory-safe languages like Java, Go, and Rust"
2. "We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees"
3. "A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical."
> The responsibility is on our ecosystem, not the developer I completely agree. "Rewrite it in Rust" is not the answer (it might be part of the answer). After spending some time laying the groundwork, leadership at my employer is receptive to this idea. But now what? How do we transform our ecosystem? Anyone know of books, training, consultants worth paying?
OTOH https://bughunters.google.com/blog/6368559657254912/llvm-s-r... is a very good read - while I don't agree with the premise of the article, it's a very good example showing how security concerns are addressed in real life with real life impact with real life problems to solve - by real engineers doing the meat work without cheap talk.