Carbon Language: An experimental successor to C++ • Hacker News Board

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

#81

Post by pron » Fri, Aug 01, 2025, 12:36 AM UTC

Animats wrote: post #76

pron wrote: post #41

Earlier quoted context omitted.

Given that Carbon's space is "languages with full interoperability with C++," I don't think D and Zig are in that space. As to "getting it right" - things are not so simple. The emphasis on memory-safety soundness is based on some empirical hypotheses, some better founded than others, and it's unclear what "getting it right" means. From a software correctness perspective, the road to sound memory safety is as follows…

> As to "getting it right" - things are not so simple. The emphasis on memory-safety soundness is based on some empirical hypotheses, some better founded than others, and it's unclear what "getting it right" means. It means eliminating undefined behavior, and unplanned interaction between distant parts of the program.

Eliminating undefined behaviour is a means to an end (reduces problematic bugs, but not all undefined behaviour is equally responsible to such bugs), and it's not a binary thing (virtually all programs need to interact with software written in languages that don't eliminate undefined behaviour, so clearly there's tolerance to the possibility of undefined behaviour).

Don't get me wrong - less undefined behaviour is better, but drawing a binary line between some and none makes for a convenient talking point, but isn't necessarily the sweet spot for the complicated and context-dependent series of tradeoffs that is software correctness.

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

#82

Post by nicoburns » Fri, Aug 01, 2025, 12:49 AM UTC

Animats wrote: post #34

"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)

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

#83

Post by nicoburns » Fri, Aug 01, 2025, 12:50 AM UTC

mihaic wrote: post #63

treyd wrote: post #26

Earlier quoted context omitted.

What's wrong with fn? It's perfectly understandable. I don't understand what the bikeshedding about keywords like this is about.

Keywords usually are quite pronounceable, and some of them are even proper words. How do you read fn?

Usually as "function"

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

#84

Post by miguel_martin » Fri, Aug 01, 2025, 1:03 AM UTC

cb321 wrote: post #52

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…

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be. Also, FWIW, it is very ergonomic for Nim to call C (though the reverse…

Nim 2 doesn’t require gc, with arc/atomicArc. The only thing you really need to be careful about is when you use ref types or custom owning types. Otherwise, manual memory management can be done in Nim pretty easily.

Hypothetically you could importcpp fns, classes, etc when compiling with nim cpp

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

#85

Post by miguel_martin » Fri, Aug 01, 2025, 1:04 AM UTC

JonChesterfield wrote: post #75

One could presumably compile arbitrary C++ to rust or D without changing semantics, then slowly go through the result making it look more native to the new language. That would either be a wholesale conversion or emitting a translation shim style thing at the boundary between legacy c++ and the new language. I'm not sure Carbon is necessary to achieve such a conversion.

Nim would be the best choice for this at the moment, imho

importcpp what you need. exportcpp for the other way around

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

#86

Post by reactordev » Fri, Aug 01, 2025, 1:09 AM UTC

cb321 wrote: post #52

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…

Not to disagree, but to amplify - FWIW, most of what you say was also the sales pitch for C++ over ANSI C in the early 90s vs. the "pure Java" mentality that shortly followed in the late 90s (with a megaton of Sun Microsystems marketing to re-write almost everything rather than bridge with JNI). People neglect how practical incrementalism can be. Also, FWIW, it is very ergonomic for Nim to call C (though the reverse…

But couldn’t one argue that’s true of most languages, they promise incremental progress toward rewriting your behemoth into miniature monoliths? I think the only one where they clearly drew the line at being able to pull in headers is .Net. You just can’t do it. Others like Golang or rust, you can point to the C headers and bam…

Honestly, while I find the syntax terse, I welcome more low level languages able to push performance.

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

#87

Post by [deleted] » Fri, Aug 01, 2025, 1:12 AM UTC

flohofwoe wrote: post #9

mihaic wrote: post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

Tbh, I wonder why modern languages still have a function keyword at all, e.g.: const add = (a: i32, b: i32): i32 => a + b; ...or any variation of the arrow-function idea...

[deleted]

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

#88

Post by miguel_martin » Fri, Aug 01, 2025, 1:15 AM UTC

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…

I don’t think this is the only reason.

You could do this with Nim, Nim 2’s ARC model is compatible with c++’s RAII. Nim supports moves, destructors, copies, etc. see https://nim-lang.org/docs/destructors.html

You can import C++ classes, member functions, free functions, etc. easily with importcpp

importcpp for the code you are incrementally porting over. You could write a libclang script to do this for you. Exportcpp for what you any code that have been ported but have dependencies in C++ land.

My best guess is they want C++ compatibility and a new language due to preferences, more control over the compiler, etc. which are all valid reasons

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

#89

Post by VikingMiner » Fri, Aug 01, 2025, 1:26 AM UTC

flohofwoe wrote: post #9

mihaic wrote: post #6

It's become a pet peeve of mine, but for the love of God, if anyone with input in Carbon is scanning this, what can be done to use "func" instead of "fn" as a keyword? That all-consonant keyword always makes it seem like I'm reading Hungarian notation when reading Rust for instance. An other options I've seen for instance in Pony, "fun", is already an English word with a completely different meaning. Even the "functi…

Tbh, I wonder why modern languages still have a function keyword at all, e.g.: const add = (a: i32, b: i32): i32 => a + b; ...or any variation of the arrow-function idea...

IMO it is far easier to read this:

    function add(a: i32, b: i32): i32 {
        return a + b;
    }

Than the example you provided and it is approximately the same length. I used to arrow functions everywhere in TS/JS and it made it difficult to read IME, and there was zero benefit. They are find for things like event handlers, promises chains etc. But I'd rather just use function when I don't have to worry about the value of this.

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

#90

Post by nicwilson » Fri, Aug 01, 2025, 1:30 AM UTC

JonChesterfield wrote: post #75

One could presumably compile arbitrary C++ to rust or D without changing semantics, then slowly go through the result making it look more native to the new language. That would either be a wholesale conversion or emitting a translation shim style thing at the boundary between legacy c++ and the new language. I'm not sure Carbon is necessary to achieve such a conversion.

This was essentially how DMD (the reference D compiler) was translated to D. However this was mostly a restricted subset of C++ common to both of them, e.g. no diamond inheritance, no operator overloading whackiness.