It's not immediately obvious from this page and GitHub org, but this is a Google led project. It's led by Chandler and the c++ toolchain team. I have no idea of it's endgoals or how open to non-Google ideas it will be.
I was frankly shocked by that goals and priorities document. The non-goals section reads like an open declaration of war against anyone whose use cases for C++ differ from GOOG and NVDA. My interpretation of Carbon is that since GOOG failed to take over the standard in favor of its narrow use cases, that they are building a new language optimized specifically for them.
> I have no idea ... how open to non-Google ideas it will be.
The most-generous attitude to take is that it will be managed similarly to Go. If your use cases and priorities are well-aligned with theirs, then feel free to use it. But while they may listen to third-party feedback, it will be their own use cases and opinions which dominate the language's development.
Why use these stock index abbrevs (or whatever they are) in this context here? GEEZ!
To the topic, it sounds a bit grumpy. If we look at languages and how many evolve... many suffer the phenomenon that they almost all are Turing complete, and try to gain concise (or simple understandable) expressiveness somehow, and then they try to not break compatibility too much to varying degrees - net result: they grow and grow where at one point they feel like too big, too much legacy dragged around (C++), the "one obvious way" lost (Python) when they cater for use case after use case.
Limiting can be good in that regard. So having key goals defined and not to cater to every small new usecase by someone is a valid attempt to not let this happen, so while I dislike Googles power, I wouldn't feel to bad with attempting this by anyone on their fresh language?!
Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us.
Projects like this have to start somewhere, but can grow and become community endeavors. We are also already seeing strong interest from other companies and organizations in participating in this experiment.
Power C++ Syntax Plus Edition
C&₹π÷×√
In Rust for example, `unsafe {}` blocks are not just "local unsafety". They can freely operate on all memory, so they are infectious and are essentially a marker for "dangerous code below, be extra careful and audit lots".
But if all code can freely interoperate with C++, how do you improve upon C++, apart from relatively isolated features like a better generics system?
To what extend can a Carbon compiler that is deeply aware of C++ semantics mitigate the pitfalls?
You can definitely massively improve upon C++ without touching its actual computation model.
Implementing a coherent vision might lead to a better language even if most stakeholders might disagree with every single change.
> That said, our experience, use cases, and needs are clearly not those of every user. We aren’t pushing to directly build consensus on these points. Rather, this is presented as a vehicle to advertise our needs from C++ as a high-performance systems language.
The point of the non-goals is simply stating things they don't care about, which is pretty reasonable. After all, it's easy to say what you want, but what are you willing to give up for it?
Compare C++ <random> or <chrono> against, say, the equivalent functionality in Rust, Go, Java, C#, etc. C++'s APIs are a bit overcomplicated, or at least they look that way if you don't know the various reasons why the C++ standard defined them that way (reasons which are probably not relevant to your use cases).
This always felt eye-rolling false to me. We can't have a better hashmap since we all need to pay for the std::unordered_map's un-needed features like bucket access. We are certainly paying for what we don't use.
Every other adoption of the meaning is misuse of what Bjarne originally meant with it.
These 2 things are C++ core principle, but they are 2 different things.
"You don't pay for what you don't use" means that I you do not use a C++ feature, your runtime performance won't be affected by this feature. For example, non virtual functions are not slower because virtual functions exist.
In our case here, if you do not use "std::unordered_map" and decide to implement your own unordered map, then it is as-if "std::unordered_map" never existed. You are not forced to use "std::unordered_map" and you own map won't be slower because it exists.
"the compiler doesn't generate worse code than if you had written the same by hand", or rather "What you do use, you couldn’t hand code any better", means that if you decided to implement a C++ feature by hand in C++ or C, your implementation could only hope to match C++ implementation. For instance calling a virtual function in C++ will never be slower than a similar handwritten late dispatch implementation.
This doesn't give me much confidence if its Corporate governance rather than open governance.
Disclosure: Former Google engineer who worked sorta adjacent to some of those people.
But yes, I agree, we should have no expectation of support for experimental or beta products.
It is not a joke.
It is a reputation that Google has earned through its actions and inactions.
As shown by https://killedbygoogle.com/ and numerous desperate posts for help [1][2][3] on this and other web sites, Google's "must launch a new shiny thing" promotion culture and abysmal customer service have eroded public trust in the long-term viability of anything that Google creates.
[1] https://news.ycombinator.com/item?id=5523992
It may have been started by mostly Googlers but they want other companies and individuals to participate
I think this is going to be an uphill battle for them and I hope they win it but I'll be skeptical unless if I start seeing radical (for google) transparency basically immediately.
Also worth pointing out that the language is not immediately worthless even if they fail or only partially succeed in this endeavor!!
Also, for what it’s worth: despite being an ISO-standard language, C++ is still heavily swayed by corporate interests, with most committee members being tied to BigCos. This has the effect of somewhat-necessarily aligning language progress with its most significant users. Without this alignment, the language might be “better” in some respects, but less useful.
- I don't use golang - As an outsider, the governance has seemed unhealthy like with how dependency management was dropped out of no where
However, it has been relatively successful. Dart's success has been more mixed. I am also looking more broadly at projects like Bazel.