Given the huge effort to make this language, I wonder if they could have directed that toward some kind of Rust-to-C++ bridge instead?
Carbon Language: An experimental successor to C++
91–100 of 200 posts
Re: Carbon Language: An experimental successor to C++
#92Earlier quoted context omitted.
I'd say the C++ community is torn. Some part of it want C++ to be Rust, with a focus on compile-time safety. Others take "C++" literally as "C with extra stuff" and value performance over safety. Companies like Google are likely to be in the former camp, as for what they are doing, security is critical. Unsurprisingly, Carbon is a Google project. Video game companies on the other hand are likely to be in the latter c…
I blame the "we won't recompile anything ever" stance from the financial organisations for the breakdown. It means C++ cannot fix mistakes, even when they harm performance, under the general name of "abi stability". Thus there is an opening for a faster language. And still for a safer one. And for an easier one to use. So all C++ has going for it is inertia. It's moribund unless the committee reconsider their stance…
Will Carbon improve the ABI situation? Will Carbon be easier to interface with from other languages?
A major role that C plays today is being the common protocol all languages speak[0]. C++ can't fill this role, and neither can Rust.
There is a huge opportunity for some language to become the next common protocol, the common ABI, that all languages share in common.
(Maybe Rust could do this, but they haven't stabilized their ABI yet, and I don't the details.)
Re: Carbon Language: An experimental successor to C++
#93Re: Carbon Language: An experimental successor to C++
#94I remember back when carbon first appeared, I immediately thought it's not gonna get popular simply because it has "fn" and "var" superficial details matter - people that stayed on C++ instead of transitioning to flashy new ones have type-before-name as part of programming identity you can have all the features in the world (and be recognized by it), but if the code doesn't _look_ like C++, then it's of no interest
Stockholm syndrome, after learning C++ syntax, surely it wasn't all for nothing, I can't accept that.
Re: Carbon Language: An experimental successor to C++
#95"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." If they can't get safety right at the design stage, they'll never get it right. We already have D and Zig in this space.
Zig is nowhere near memory safe. Even some basic semantics (passing arguments as values or references) are horribly broken. https://github.com/ziglang/zig/issues/5973
no need for memory safety to be in the language. It can still be checked at compile-time:
Re: Carbon Language: An experimental successor to C++
#96Re: Carbon Language: An experimental successor to C++
#97I think this page describes "what" but not "why" of Carbon. Carbon exists so that it's possible to migrate a large C++ code base, like Chrome, from C++ to something saner, incrementally. The most important attribute of Carbon is not the specifics of the syntax but the fact that it's designed to be used in a mixed C++ / Carbon code base and comes with tooling to convert as much of C++ as possible to Carbon. That's wha…
> I think this page describes "what" but not "why" of Carbon.
Maybe the page was updated recently, but there is a "why" link near the top:
https://docs.carbon-lang.dev/#why-build-carbon
What I would like to see is more documentation on the "why not" that summarizes why other languages and proposals are not sufficient. For example, Safe C++ proposal[1] appears to satisfy all requirements, but I can't find any reference to it.
Re: Carbon Language: An experimental successor to C++
#98"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." If they can't get safety right at the design stage, they'll never get it right. We already have D and Zig in this space.
Swift seems to be doing a decent job of this (and C++ interop for that matter)
> Swift seems to be doing a decent job of this
It keeps adding keywords and it has become way harder to keep it in your head. It’s over 220 at this point. Don’t take my word for it, Swift creator doesn’t agree with its current direction either.
Re: Carbon Language: An experimental successor to C++
#99Earlier quoted context omitted.
Zig is nowhere near memory safe. Even some basic semantics (passing arguments as values or references) are horribly broken. https://github.com/ziglang/zig/issues/5973
no need for memory safety to be in the language. It can still be checked at compile-time: https://www.youtube.com/watch?v=ZY_Z-aGbYm8
This is a cool project, but it doesn’t address my original issue with Zig, which is that the language’s semantics is not even specified. That is, we cannot define what a “memory safe Zig program is” as we cannot even define what a Zig program is! (Unless you define the semantics of a Zig program in terms of the implementation/translation to IR, which is fragile / bad.)
Second, I would be surprised if the static analyses in the tool are precise enough for real-world Zig programs. For example, it is undecidable to determine whether a function “takes ownership” of an argument pointer. In particular, if you want to avoid false negatives, the “free after transfer” case needs to be conservative, but then you almost certainly will flag false positives.
Re: Carbon Language: An experimental successor to C++
#100Earlier quoted context omitted.
...and Swift w/ Obj-C
Swift can also 2-way operate with C++. Its coverage of the C++ language is incomplete but I suspect it might outpace Carbon.
I need to learn more about that. I know that the Ladybird folks want to use it inside their C++ project.