C++ sucks: It’s no good on memory safety, it's unergonomic, has far too much legacy cruft and suffers from gatekeepers who won’t move with the times. Enter: Carbon.
Chandler Carruth (pictured) announced it last week at the Cpp North conference in Toronto. Originally a Google-sponsored experiment, the team wants Carbon to be a respectful, inclusive, fully open-source language that we can easily migrate the world’s 50 billion lines of C++ to.
There’s nothing like a bold goal. In this week’s Secure Software Blogwatch, we wonder if the world needs yet another “better C.”
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Tricking AI Image Recognition.
[ Get key takeaways from a survey of 300+ professionals on software security. Or, download the full report: Flying Blind: Firms Struggle to Detect Software Supply Chain Attacks ]
C++ WG no longer apt?
What’s the craic? Joab Jackson reports—“Google Launches Carbon”:
“Modern programming principles”
Frustrated by the slow evolution of C++, Google engineers have launched a new “experimental” … language, called Carbon. … Just as Microsoft built Typescript to update JavaScript, and Kotlin was created to shore up weaknesses in Java, Carbon could serve as a successor language to C++.
…
Long the language of choice for building performance-critical applications, C++ is plagued with a number of issues that hamper modern developers. … It has accumulated decades of technical debt. [Its] evolution is also stymied by a bureaucratic … sequestered development process.
…
Carbon will be built on a foundation of modern programming principles, including a generics system [and] memory safety. … Carbon designers will look for ways to better track uninitialized states, design APIs and idioms that support dynamic bounds checks, and build a comprehensive default debug build mode. [They] will also set out to create a built-in package manager [and] write translation tools to migrate C++ code into Carbon.
Just to hammer the point home, Kyle Bradshaw says it “aims to be C++ successor”:
“Open for pull requests”
Over the years, Google has created a few programming languages, some of which have become more popular and prominent than others. For example … Go was created for the purpose of improving the development of servers and distributed systems. … Meanwhile, the Dart programming language, originally intended as something of an alternative to JavaScript, didn’t reach mainstream popularity until the release of Flutter.
…
Some may suggest that Rust, originally a Mozilla project that has since grown to have a significant public following, is a successor to C++. [But] it doesn’t have the same “bi-directional interoperability” of something like Java & Kotlin, making it difficult to steadily migrate. … The goal is to make migrating from C++ to Carbon as easy as possible.
…
While Carbon got its start within Google, the team understands and has shared online that for it to have any future success, Carbon needs to be “an independent and community driven project.” … The project’s code is hosted publicly on GitHub and is open for pull requests, while Carbon’s culture is outlined to be accessible and inclusive.
What about memory safety? Chandler Carruth and friends commit to “an experimental successor to C++”:
“A safe Carbon subset”
Safety, and especially memory safety, remains a key challenge for C++ and something a successor language needs to address. Our initial priority and focus is on immediately addressing important, low-hanging fruit: …Once we can migrate code into Carbon, we will have a simplified language with room in the design space to add any necessary annotations or features, and infrastructure like generics to support safer design patterns. Longer term, we will build on this to introduce a safe Carbon subset. This will be a large and complex undertaking, and won't be in the 0.1 design. Meanwhile, we are closely watching and learning from efforts to add memory safe semantics onto C++ such as Rust-inspired lifetime annotations. (See Carruth's Carbon announcement video.)
- Tracking uninitialized states better, increased enforcement of initialization, and systematically providing hardening against initialization bugs when desired.
- Designing fundamental APIs and idioms to support dynamic bounds checks in debug and hardened builds.
- Having a default debug build mode that is both cheaper and more comprehensive than existing C++ build modes even when combined with Address Sanitizer.
But what makes it different? That’s exactly what cogman10 was wondering:
“What Carbon can do that Rust can’t”
If you are like me and wondering "What makes Carbon different from Rust or Zig?"
In other words, what Carbon can do that Rust can't do, is take a C++ class with a `foo` method and call that method. Or create a class with a `foo` method and call that method from C++. Probably one of the biggest hurdles to get over in C++ interop.
- The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions.
- A willingness to expose the idioms of C++ into Carbon code—and the other way around, when necessary to maximize performance. …
- The use of wrappers and generic programming, including templates, to minimize or eliminate runtime overhead.
A well-read Brain-Fu quotes Bjarne Stroustrup:
“There are only two kinds of languages: The ones people complain about, and the ones nobody uses.”
…
Rust is not better than C/C++. Its current popularity is mostly hype. It has some specific benefits over C/C++ but those come with some distinct costs. If its adoption really does get anywhere near the level of C/C++ … everyone will be complaining about those [costs] just as much … as people complain about woes in C/C++.
Two can play at that game. Evans O offers this African proverb:
“An axe that contends with rock in battle suffers blunt edges.”
…
C++ is an unshakable rock. … I think Carbon is starting on a wrong footing since its intention is to replace C++.
…
C++ 23 is around the corner! Can Carbon catch it? I suggest Google should aim at improving on the evolution process of C++ (which I think is where the issue lies) rather than boast of replacing it. For example, Google can create a modern package manager for C++ so that its appeal to mainstream developers can be rekindled.
But isn’t this really about Google falling out with the C++ working group? saagarjha seems to say so:
Google uses C++ differently than everyone else. … In particular, they have a lot of statically linked code from a monorepo that gets recompiled all the time. This has caused them to put up proposals to “fix” the language that nobody else will support and don’t get adopted, because they break the ABI or backwards compatibility in ways that are unacceptable to the others who participate. It seems like this language is the result of that frustration and subsequent soft-withdrawal from the C++ WG.
…
I feel like Google designed this to solve their problems with C++ and is just throwing it out there if people are willing to adopt it because it’s there and Google says it’s good, just like how Go gained traction. [But] it seems pretty clear that the needs of this will be driven by Google.
Of course, real programmers stick to C or assembler. wakeboarder has a “get off my lawn” moment:
Devs now are … completely detached from the underpinnings of a computer. Many devs I've talked to … don't even know how a malloc works or caching strategies. They also don't know how the stack and heap works.
Meanwhile, Junta just jokes:
I'm not particularly excited or upset about it. Guess you could say I'm carbon neutral.
And Finally:
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Bryce Adelstein Lelbach
All Stories
Software Supply Chain Security
Dev & DevSecOps
CI/CD Security
Container Security