Live data from Hacker News

Google Launches Carbon, an Experimental Replacement for C++

thenewstack.io

181–190 of 243 posts

Re: Google Launches Carbon, an Experimental Replacement for C++

#181

How to make your replacement for a C language Google-able: name it after an API for a C language: Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Compare also keywords or key terms: Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need…

Carbon API is so old that this pretty much isn't issue. You have to google explicitely for "Carbon API" for it to show up. Whether even now, "carbon programming" or "carbon code" give results for Carbon language - and some other non-c++ libs named Carbon. Even "carbon" by itself gives me some Carbon language links.

At first I wanted to disagree (I remember the whole "Cocoa or Carbon" dilemma for Mac developers in the early 00s), but then I just realized that I'm old.

Carbon (the Mac API) only existed to enable developers to more easily port Mac 8/9 applications to OS X, which was over 20 years ago. The Carbon API was officially discontinued in 2019 with Catalina.

The Carbon API served its purpose, it's now officially "dead", so I agree - I don't see much of an issue with giving a new technology the same name.

Re: Google Launches Carbon, an Experimental Replacement for C++

#182

Earlier quoted context omitted.

Carbon API is so old that this pretty much isn't issue. You have to google explicitely for "Carbon API" for it to show up. Whether even now, "carbon programming" or "carbon code" give results for Carbon language - and some other non-c++ libs named Carbon. Even "carbon" by itself gives me some Carbon language links.

Don't forget they named language go, while language named Go! already existed. They just don't care. https://en.m.wikipedia.org/wiki/Go!_(programming_language)

At least they didn't name it after a very popular existing language and then tack "script" on the end...

Re: Google Launches Carbon, an Experimental Replacement for C++

#183

Earlier quoted context omitted.

> Rust isn't any more complex, but it's not radically simpler either. Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.

Instead Rust has a borrow checker, procedural macros of different types, half a parallel language when using unsafe, etc... And by the way, Rust does have pointer arithmetic. It's not clear to me that either is simpler or easier. The big point of Rust is really memory safety, not ease of use or simplicity.

Rust's slogan is: "A language empowering everyone to build reliable and efficient software."

Now, that "everyone" there has a bunch of social consequences, like you're going to see a bunch more diversity in Rust's community than we've traditionally seen in this sort of endeavour. But it also means technically there's work put in to actually deliver on the slogan by making it easier for everyone to use the language.

This is how Rust has those excellent compiler diagnostics. That's not an accident, it's part of "empowering everyone". Experts could manage with a compiler that outputs terse errors like "Syntax error, line 14" but that's not going to empower everyone.

Re: Google Launches Carbon, an Experimental Replacement for C++

#184

Earlier quoted context omitted.

> Rust isn't any more complex, but it's not radically simpler either. Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.

Instead Rust has a borrow checker, procedural macros of different types, half a parallel language when using unsafe, etc... And by the way, Rust does have pointer arithmetic. It's not clear to me that either is simpler or easier. The big point of Rust is really memory safety, not ease of use or simplicity.

Yes, but C++ isn’t complex because it set out to be complex, it’s complex because they’re constantly trying to enhance it whilst maintaining backwards compatibility with a system that was originally basically just a big set of CPP macros.

Rust has a heck of a lot of features, but it’s got nothing like the “too perfect forwarding” problem of the language behaviour just being plain hard to predict.

Re: Google Launches Carbon, an Experimental Replacement for C++

#185

I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is exp…

> Rust isn't any more complex, but it's not radically simpler either. Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.

Why are classes automatically somehow assumed as complex? Rust's structs are basically classes without class inheritance.

Re: Google Launches Carbon, an Experimental Replacement for C++

#186
post #169
post #161

Earlier quoted context omitted.

The pun is that C is the chemical symbol for carbon.

But it's a C++ replacement, not a C replacement, so they should have named it Nitrogen. Edit: it appears that Nitrogen and Phosphorus are already used by Lisp dialects.

C++ is still carbon, just missing a couple of electrons.

Re: Google Launches Carbon, an Experimental Replacement for C++

#187

Earlier quoted context omitted.

Rust will require a complete re-write or extensive work implementing a C-like interface for your C++ API. Carbon will be able to use C++ classes natively, including calling methods etc. I think Carbon will be a much better choice for extending a C++ project. Rust might be a good choice if you are able to start from scratch or the project has C bindings.

How did the firefox team handle it? They have moved parts to Rust while the rest is still C++.

Firefox is porting or replacing entire libraries.

(The idea with Carbon is you could replace specific C++ classes or headers.)

Re: Google Launches Carbon, an Experimental Replacement for C++

#188
post #39

Is there already a substantial amount of this in Google’s repos? It would be in character for them to reveal this after it’s already well-established internally.

There's enough gaps in the specification (move/copy situation in particular) that would make me hesitant to use this for any production code. Given that the code seems to date from WG21's rejection of the Google-led "we want to add a hard ABI break in C++23" proposal, the project is barely 2 years from literal first commit, which is likely too short to attract any substantial internal usage.

I think this is supposed to be the pre-alpha-broken-preview-dont-use-in-prod stage. So don't use it in prod :)

Re: Google Launches Carbon, an Experimental Replacement for C++

#189
post #43

Earlier quoted context omitted.

The move situation would be less confusing to newcomers if they had called it what it really does, std::become_rvalue_reference or something.

I agree that it should have been named better (rvalue_cast might have worked) but that wouldn't have solved the core problem: Does f(std::become_rvalue_reference(x)) make a copy of x? It's more obvious that it might but I still lack the facility to make it cause a compile time error if it would (except changing x's class to disallow any copies at all).

In general you can't answer these questions by reading the call site. You have no idea what kinds of intermediate functions are implied by f(x). Maybe f() doesn't take an X at all, maybe it takes a Y and there's an implicit Y::Y(const X&) hanging around, or perhaps there is an X::operator Y(). You can only understand f(x) by reading the definitions of f, its argument type, and X.

Re: Google Launches Carbon, an Experimental Replacement for C++

#190

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

so basically Google C
Post reply on HN