Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carbon Language: An experimental successor to C++

docs.carbon-lang.dev

Post reply on HN
Print view View original

151–160 of 200 posts

Re: Carbon Language: An experimental successor to C++

#151

Post by samuell »

kjksf wrote: post #50

I 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…

Yeah, perhaps the GitHub README [1] had been better ... but it seemed like the most "official" page.

[1] https://github.com/carbon-language/carbon-lang/?tab=readme-o...

Re: Carbon Language: An experimental successor to C++

#152

Post by aw1621107 »

justcuriousab wrote: post #136
omoikane wrote: post #97

Earlier quoted context omitted.

> 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 referenc…

Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.

> Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation?

Technically speaking the clauses on either side of the "or" aren't mutually exclusive. You can have a "full, correct, fully compliant, reference implementation" that is also a closed-source implementation!

Well, unless the implication that Circle isn't "full, correct, [and] fully compliant", in which case I feel I should ask "with respect to what?" and "why do you need those requirements?"

Re: Carbon Language: An experimental successor to C++

#153

Post by justcuriousab »

pjmlp wrote: post #143
justcuriousab wrote: post #129

Earlier quoted context omitted.

> It's not possible to port a millions line C++ code base, like Chrome, to another language so large C++ projects are stuck with objectively pretty bad language and are forced to continue to use C++ even though a better language might exist. One good aspect about C++ is its backwards compatibility or stability. Also a drawback, but companies not having to spend huge amounts of time, expertise and money rewriting thei…

I can write C++98 or C++11 code that will fail in a C++23 compiler, because C++ also isn't 100% backwards compatible.

But the changes required are generally significantly smaller and less frequent, right?

Re: Carbon Language: An experimental successor to C++

#154

Post by justcuriousab »

aw1621107 wrote: post #149
justcuriousab wrote: post #129

Earlier quoted context omitted.

> It's not possible to port a millions line C++ code base, like Chrome, to another language so large C++ projects are stuck with objectively pretty bad language and are forced to continue to use C++ even though a better language might exist. One good aspect about C++ is its backwards compatibility or stability. Also a drawback, but companies not having to spend huge amounts of time, expertise and money rewriting thei…

> Rust is often somewhat stable, but not always. > https://internals.rust-lang.org/t/type-inference-breakage-in ... > https://github.com/rust-lang/rust/issues/127343 > 300 comments on Github. > https://github.com/NixOS/nixpkgs/pull/332176 Might worth noting that this change technically doesn't violate Rust's stability guarantees since type inference changes and/or adding new impls are exempt. Of course, that doesn't…

I wonder if the guarantees could be amended, considering the reactions from the Rust community.

Re: Carbon Language: An experimental successor to C++

#155

Post by bbkane »

gituliar wrote: post #126
dazzawazza wrote: post #118

Earlier quoted context omitted.

These are strong points and I think the methodology behind Carbon is the correct one. The elephant in the room is that once Google decide to drop Carbon my existing code base will be dependant on a dead technology and then I am screwed. I find it hard to trust Google to maintain any software nor to write software that is maintainable by a community. They write software for themselves and themselves alone.

For me Go is a success story.

I'd say Dart/Flutter is as well

Re: Carbon Language: An experimental successor to C++

#156

Post by justcuriousab »

aw1621107 wrote: post #152
justcuriousab wrote: post #136

Earlier quoted context omitted.

Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.

> Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Technically speaking the clauses on either side of the "or" aren't mutually exclusive. You can have a "full, correct, fully compliant, reference implementation" that is also a closed-source implementation! Well, unless the implication that Circle isn't…

But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

Re: Carbon Language: An experimental successor to C++

#157

Post by justcuriousab »

pjmlp wrote: post #141
justcuriousab wrote: post #136

Earlier quoted context omitted.

Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Circle, as far as I know, is closed-source.

Most languages including C and C++, had leading closed source implementations, that is why being standardised by ISO mattered.

But standardization also matters for avoiding vendor lock-in, right?

Like, Python and Javascript both have many "implementations", and those are some of the most popular languages. Python does not have an ISO specification. But Javascript does have an Ecma standard, ECMAScript.

Rust is getting another implementation in the form of gccrs. And there is work on a specification for Rust https://rustfoundation.org/media/ferrous-systems-donates-fer... . Arguably not a standard, but still helpful.

Re: Carbon Language: An experimental successor to C++

#158

Post by aw1621107 »

justcuriousab wrote: post #156
aw1621107 wrote: post #152

Earlier quoted context omitted.

> Did Safe C++ ever have a full, correct, fully compliant, reference implementation, or was there only (closed-source) Circle as some kind of reference implementation? Technically speaking the clauses on either side of the "or" aren't mutually exclusive. You can have a "full, correct, fully compliant, reference implementation" that is also a closed-source implementation! Well, unless the implication that Circle isn't…

But Safe C++ and Circle are different languages, right? And Circle is not the same as the Safe C++ proposal that was submitted, right? There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere. I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

> But Safe C++ and Circle are different languages, right?

Eh, bit of a mixed bag, I think, depending on the context in which the words are used. "Circle" can refer to the compiler/toolchain or the set of C++ extensions the compiler implements, whereas Safe C++ is either the proposal or the extensions the proposal describe. As a result, you can say that you can compile Safe C++ using Circle, and you can also describe Safe C++ as a subset of the Circle extensions. I wouldn't exactly describe the lines as well-defined, for what it's worth.

> There are presumably differences between them, and I do not know what those differences are, and I do not know if those differences were documented somewhere.

They're sort of documented indirectly, as far as I can tell. Compare the features in the Safe C++ proposal and the features described in the Circle readme [0]. That'll get you an approximation at least, albeit somewhat shaded by the old docs (understandable given the one-man show).

> I cannot find any occurrences of "reference implementation" in the Safe C++ draft.

The exact words "reference implementation" may not show up, but I think this bit qualifies (emphasis added):

> Everything in this proposal took about 18 months to design and implement in Circle.

[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...

Re: Carbon Language: An experimental successor to C++

#159

Post by dnautics »

tylerhou wrote: post #99
dnautics wrote: post #95

Earlier quoted context omitted.

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 analy…

of course. There will absolutely need to be a way to specify intent in certain cases or override the judgement of the checker. That may come in the form of external annotation, or possibly internal annotation, which in principle is achievable using the same technique as you see in the "unitful" demo, though that's not ideal.

as for zig being specified, well, it's pre 1.0, and the authors have I believe, specifically called out specification as being "the first priority after 1.0".

Re: Carbon Language: An experimental successor to C++

#160

Post by pjmlp »

justcuriousab wrote: post #153
pjmlp wrote: post #143

Earlier quoted context omitted.

I can write C++98 or C++11 code that will fail in a C++23 compiler, because C++ also isn't 100% backwards compatible.

But the changes required are generally significantly smaller and less frequent, right?

If the build breaks when changing the value of -std= (or equivalent), it hardly matters how big it is.
Post reply on HN