> Seamless interop where safe Rust APIs are made callable from C++ requires C++ users to follow Rust borrow checking rules.
Their complaints about borrow checking rules at the interop layer ring hollow to me. Whether the new code is being written in Rust, Carbon, or C++... the lifetime of shared memory must be well-understood by the developer writing the code. Rust just makes this problem explicit and enforceable. Sweeping the problem under the rug isn't a better option.
> However Rust imposes stricter rules than C++, disallowing some design choices that were valid in C++.
The word "valid" is doing a lot of heavy lifting here, and I'm generally skeptical of these "valid" architectures. If it is so easy to know that these architectures are valid, why do we still see so many memory safety issues in Google's C++ code? Incrementally restructuring C++ code to be more provably correct doesn't sound like a terrible thing... in fact, it sounds like exactly what they should be doing.
> However, we are not certain that [C++ can be migrated to Rust incrementally]
Firefox is a large, historically C++ codebase that has undergone incremental rewrite into Rust for years now. It seems quite certain that this is both possible and practical! Where is the uncertainty? Of course, Mozilla's budget pales in comparison to Google's.
Rust is an extremely extensible language, and it is absolutely possible for Google to build their own version of `rust-bindgen` that suits their particular C++ codebase's idioms. That would be a much simpler undertaking that achieves their goal of incrementally adopting memory safety.
I hate to disparage new languages, but this feels like Swift all over again... it's just NIH. At this point, the die has been cast, and I'm sure it would be career suicide in Google for anyone behind the Carbon project to admit at this stage that "actually, the project turned out to be unnecessary after a discussion on HN!", so I don't expect to change anyone's mind. I'm just wasting my breath making obvious counterarguments that I'm sure have already been considered and ignored.
To be extra clear, I would love to see a company like Google take on the challenge of building an ergonomic language that exceeds Rust in terms of safety, but Carbon is a half-measure that doesn't pretend otherwise. If all of Google's C++ code is magically rewritten in Carbon, they will still apparently have memory safety problems based on what Carbon's README says... and then it'll be time once again to consider "maybe we should have ported to Rust after all". It just feels like such a waste.
It's actually a big problem. There's a whole lot of Rust library API's that are only provided with an idiomatic "safe" interface, but this actually imposes stronger, more demanding preconditions on those API calls than are warranted by the actual code, which could easily work with e.g. raw (possibly aliased) pointers, or owned-but-pinned (non-movable) data. This creates unneeded pitfalls in Rust-C/C++ interop. The counterargument is that future versions of that library code might benefit from those stronger preconditions, but that's more of a theoretical point, it just doesn't apply in most cases.
If they needed to fork the Rust compiler to pessimize a few optimizations that the Rust compiler would normally do (that would invalidate such unsafe C++ code with additional UB), even that would be far less effort than inventing their own entire new language and ecosystem from scratch. That is without considering how Google could work with the Rust Core Team to contribute solutions for ergonomic issues they're encountering in the interop process.
When the alternative is "building an entire, general purpose programming language", there are a lot of other things you can do that would be much easier.
And, as previously mentioned, Carbon is only addressing the low hanging fruit... it isn't stated anywhere I've seen that they even intend to achieve parity with Rust. All of this effort, just for a lesser outcome.
I'm sorry that I'm frustrated at big companies choosing to take half measures that seem even more expensive than the full measure. I have used Rust professionally for years; I'm clearly biased, but it's not that hard. The level of safety that Rust provides should be table stakes in discussions of unmanaged languages... not the ceiling for what we can possibly imagine, but Carbon is a statement that Rust's bar is too high for Google to reach, and that's pretty depressing.
"Pessimizing" the compiler is not a solution, UB is still UB. You'd have to actually look at what the code does in detail and provide a generalized interface to it, possibly needing to introduce new "unsafe" blocks in the process and prove their safety.
I addressed this when I talked about a compiler fork. Google could maintain a patchset against the Rust compiler that makes this behavior well-defined in a way that suits them during the transition period as C++ code is rewritten. Or they could work with the Rust Core Team to address this issue in a way that is favorable to them over the next year or two. Either of these options are much less work than developing an entirely new language and ecosystem.
As far as I can tell, Google tried neither option.
Still, Mozilla and others have gotten along just fine as it is.
To be clear, this is "forever". I don't think anyone involved has an expectation to truly get rid of Google's existing C++ codebase ever. So the question is, do you really want Google to fork rustc to implement some google specific UB handling? Is that good or fair to the rust community?
Even if it was, the HN comments would be along the line of "Google is using an embrace/extend/extinguish approach to force rust to do certain things bypassing the normal rust language processes", and they'd in some ways be correct! Could rust really choose different semantics from the already existing one, or would google-rust implicitly be a standard that rust would need to support?
Would that be a good idea for anyone?
> Still, Mozilla and others have gotten along just fine as it is.
IIUC, one of the driving factors behind this is that vanilla C++ is too slow, and ABI compatibility prevents up-streaming certain performance improvements. So what works for Mozilla probably doesn't work here, because what works for Mozilla has a performance penalty. Sure it's small, but that's going in the wrong direction.
I guess I didn't finish my thought in that comment, because it isn't forever... it's only until either the C++ is gone, or the Rust language has developed an equally acceptable alternative (which could be upstreamed by Google, or come from somewhere else).
And realistically, the C++ would never have to go away entirely for this UB handling fork to become unnecessary, depending on the driving factors. Some code paths are more performance sensitive than others, and these tend to represent a small portion of the overall code. Once the performance sensitive code paths are rewritten, it matters less whether there is a small performance penalty for the remaining C++ code that is less sensitive to performance. But, at Google Scale, the cost of the developer-hours to maintain that fork would probably be less than the cost of the small increase in CPU hours that removing the fork would result in, so... yeah, maybe forever or until there is an upstream solution. Maintaining a patchset like this would still cost way less than maintaining an entire compiler and all the language tooling needed to support that language... does anyone really disagree? A new language is far more than just a compiler, let alone a patch for a compiler.
> Would that be a good idea for anyone?
IMHO, it definitely seems better than Carbon.
I doubt that Chandler would lose his job if this project is abandoned. In fact, I'd say chances it is abandoned (at least, mothballed, never to be revived) are significant so if Chandler's job does hang on this work that was a bad idea. It's an experiment, I personally think it's looking in the wrong place, but of course the point of experiments is that you don't know what the results will be. I doubt that Chandler has labelled this an experiment without knowing that.
So, my expectation is that probably Carbon won't even complete design, but if Chandler leaves Google that won't be why.
That's really not true and we can look at other languages to see the various amounts of un-true it is.
If ABI constantly changes then what you said is possibly true, but nobody is actually proposing that. The idea instead would be breakage along a std version. Like C++23 would be an ABI break. In the same way Java has had various ABI breaks over the years. You'd be blocked on taking the new ABI until all your dependencies have released updates, sure, but this isn't unheard of or unsolvable.
It's also pretty much what you expect from any semvar library, too. API/ABI breaks are quite common outside of monorepos, after all. As long as it's appropriately documented (such as with a major version bump) and there's appropriate dependency tracking, the world can handle it fine.
The C++ committee seems to be extremely shy from going this route, though. Even though C++11 triggered some ABI breaks ( https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... ) and everyone seems to have gotten along with that just fine.
Plenty of people discuss the matter.
You just ship 2 version compiled targets of std libs
This seems like Google’s response to
1. Rust not being sufficiently “Go-like” (in the sense of the “The key point here is our programmers are Googlers, they're not researchers” quote) where C++ lets a bunch of people who are not really experts in the language write footguns that Google has to deal with when they cause problems at scale. They want a dumbed-down language (some would use words like approachable/safer/whatever here) for them so nobody will send in CLs with ”clever” code that causes headaches later. I guess they’ll need to have generics but I’m guessing that choices will be made to avoid introducing advanced type theory, functional programming, etc into the language.
2. Google uses C++ differently than everyone else who uses C++. 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 haven’t looked at the design much yet beyond just the simple examples and I think it mostly looks reasonable, but 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. Sometimes Google does make good things :) Some Go developers would say that about Go, I’m sure. But if you’re using this, it seems pretty clear that the needs of this will be driven by Google, and the above two points are probably things you should keep in mind as you watch it evolve.