Hacker News Reader

Comment by brandmeyer | Hacker News Reader

> A key example of this is the committee's struggle to converge on a clear set of high-level and long-term goals and priorities aligned with ours [https://wg21.link/p2137].

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.

View on HN

(one of the Carbon leads)

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.

while we have you here, may I ask why is it called Carbon? It is because the symbol for atomic carbon is C ? :)

To make it as hard to search for solutions online as it is for "go".

Shouldn't be a problem if they're both created by a search engine company.

What's a good name?

Power C++ Syntax Plus Edition

C&₹π÷×√

Tangent. Absolutely loved your CPPCON talks. Thanks.

The README doesn't expand on what is probably the most challenging problem: how do you achieve effortless C++ interop without burdening Carbon with all the odd behaviour and memory safety / UB issues prevalent in 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?

C++ has many many issues other than memory safety. For example implicit type conversion, template duck typing, the include system, the very very very complicated name lookup system, a gazillion footguns inherited from C.

You can definitely massively improve upon C++ without touching its actual computation model.

Starting by using a sane set of compiler flags to make code safer by default.

Will Carbon natively support exceptions or is it solely going the Rust `Result<T, E>` route ?

This suggest that Carbon itself won't support exceptions: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

> GOOG and NVDA

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?!

Oh so that's what they are.

Bits are in such short supply these days that it's necessary to save 32 of them. Think of all the things you could be doing with those 32 bits!

Must be another one of those supply chain disruptions.

It's an implication that the driving force for the development is money. By the way, jump on the GEEZ train, that stock's gonna go through the roof!

I really don't see that. At the very start they say

> 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?

I don't necessarily agree with all their design goals, but it is unfortunately true that getting a large coherent change through the C++ committe is an herculean task. The language ends up doing a random walk via small steps through the design space without a coherent long term vision, because nothing else is feasible.

Implementing a coherent vision might lead to a better language even if most stakeholders might disagree with every single change.

There are weird governance issues with the C++ committee too. Acceptance or rejection of a feature can depend on which reps just happen to show up that day.

Reply on news.ycombinator.com