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

Carbon Language: An experimental successor to C++

github.com

Post reply on HN
Print view View original

371–380 of 521 posts

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

#371

Post by feminintendo »

Maursault wrote: post #365

Why "Carbon?" I just want to known if I a missing something subtle... or if it is just C, the symbol for carbon. Developers need better and unique names for their products. I realize no one will care because no one is using it anymore, but Carbon was already taken by Apple for their Objective C API.[1] That both are pretty much in the same space with the same name is sure not to cause any confusion. [1] https://en.wi…

I'm not following you at all. Carbon was an API for Mac OS X, not a programming language. It was a C API, not an Objective-C API. (Maybe you are mistaking it for Cocoa, which required Objective-C on 64-bit platforms.) What relationship does this have to the new Carbon programming language?

Google did clobber another programming language with Go.[1] It was a truly a-hole move.

[1] https://en.wikipedia.org/wiki/Go_(programming_language)#Nami...

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

#372

Post by kllrnohj »

mkoubaa wrote: post #341
saagarjha wrote: post #109

(Speaking only for myself, I just watch from the sidelines and have no involvement) This seems like Google’s response to 1. Rust not being sufficiently “Go-like” (in the sense of the “The key point here is our programmers are Googlers, they're not researchers” quote) where C++ lets a bunch of people who are not really experts in the language write footguns that Google has to deal with when they cause problems at scal…

I work at smaller scale c++ than google and I found most of their proposals reasonable but undoable for practical reasons rather than first principles reasons. For instance compiler vendors who have a veto power over language changes strongly prefer not breaking ABI. ABI changes are fine if you build the world at every commit, but also if you don't have legacy. C++ users 200 years from now would most likely benefit f…

> ABI changes are fine if you build the world at every commit, but also if you don't have legacy.

That's really not true and we can look at other languages to see the various amounts of un-true it is.

If ABI constantly changes then what you said is possibly true, but nobody is actually proposing that. The idea instead would be breakage along a std version. Like C++23 would be an ABI break. In the same way Java has had various ABI breaks over the years. You'd be blocked on taking the new ABI until all your dependencies have released updates, sure, but this isn't unheard of or unsolvable.

It's also pretty much what you expect from any semvar library, too. API/ABI breaks are quite common outside of monorepos, after all. As long as it's appropriately documented (such as with a major version bump) and there's appropriate dependency tracking, the world can handle it fine.

The C++ committee seems to be extremely shy from going this route, though. Even though C++11 triggered some ABI breaks ( https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a... ) and everyone seems to have gotten along with that just fine.

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

#373

Post by imron »

JoshTriplett wrote: post #236
mempko wrote: post #130

Earlier quoted context omitted.

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

C++11 was where C++ lost me, and I went from saying I knew C/C++ to saying I know C.

C++14 was what got me in to Rust.

I'm still in the C++ world for work, and have kept reasonably up to date with things to C++17, but I'm sitting here looking at C++20 and wondering is it really worth the effort...

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

#374

Post by pkasting »

zozbot234 wrote: post #363
pkasting wrote: post #358

Earlier quoted context omitted.

I work on the Chrome team. Safety is not the only goal for the codebase. There's also things like readability, maintainability, performance, and correctness. Finally, there's the need to chart a course towards how you get there. Rust provides many of these, but not much of an incremental path there. Carbon aims to provide many of these, but not as much safety as Rust (likely, even in the future). The upshot: there ar…

It's a web browser. If safety is not the one overarching concern when developing a web browser, of all things, the Chrome dev team is clearly dropping the ball. > Rust provides many of these, but not much of an incremental path there The incremental path is provided since you can refactor stuff into Rust at a scale as tiny as individual functions. Even an "unidiomatic", C/C++-like interface to "unidiomatic" unsafe Ru…

You cannot refactor C++ to Rust at the individual function level without good RustC++ interop. The Carbon docs go into this at a sufficient level of detail; TLDR, interop paths exist but are insufficient and are actively being researched (and Chrome devs are heavily involved in said research).

And as to your initial comment, of course safety is important, but if you don't understand why things like maintainability and performance are _also_ critically important, then your opinion is not sufficiently well-informed.

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

#375

Post by bialpio »

wiseowise wrote: post #288
bialpio wrote: post #156

Earlier quoted context omitted.

GP mentioned C++ being replaced by Rust - I'd say that a replacement should be as capable as the thing it replaces, so if that's the claim, then Rust should be at the very least OK for GUI apps. If it's not, then that's also okay, but let's not call it a replacement then. :-) I'm personally excited to see how all those languages will influence each other!

You’re comparing framework for one language to another language.

I don't think I understand - where is any kind of framework mentioned? And even if frameworks were mentioned, I think it's a fair comparison to say "language A has battle-proven / easy-to-use / etc. framework to achieve X, but language B doesn't".

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

#376

Post by bialpio »

pipeline_peak wrote: post #179
bialpio wrote: post #162

Earlier quoted context omitted.

We may need more time. IIRC, Firefox is incorporating some code written in Rust, and there's also Servo.

Mozilla laid off Servo's developers and a lot of the core Firefox Team 2 years ago. Servo is dead

But it is a cross-platform GUI app, which the post was about. Granted, it is (or was?) experimental (so not production-grade), but the PoC for GUI app in Rust should be there (assuming they didn't use something else just for the GUI, I'm not an expert on Servo).

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

#377

Post by olliej »

cogman10 wrote: post #21

If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…

Zig is to my knowledge specifically designed to have they kinds of use after free that C and C++ have. Their claim is not to “hide” allocation by requiring everyone to implement manual retain and release.

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

#378

Post by billsnow »

Seems neat, but it looks like the major thing is the syntax. Of course c++ syntax is insane and should be updated, but i cant shake the feeling that c++ developers secretly love it. Scanning c++ code for a seasoned c++ developer is like the bushmen of the kalahari scanning the african savanna.

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

#379

Post by Maursault »

feminintendo wrote: post #371
Maursault wrote: post #365

Why "Carbon?" I just want to known if I a missing something subtle... or if it is just C, the symbol for carbon. Developers need better and unique names for their products. I realize no one will care because no one is using it anymore, but Carbon was already taken by Apple for their Objective C API.[1] That both are pretty much in the same space with the same name is sure not to cause any confusion. [1] https://en.wi…

I'm not following you at all. Carbon was an API for Mac OS X, not a programming language. It was a C API, not an Objective-C API. (Maybe you are mistaking it for Cocoa, which required Objective-C on 64-bit platforms.) What relationship does this have to the new Carbon programming language? Google did clobber another programming language with Go.[1] It was a truly a-hole move. [1] https://en.wikipedia.org/wiki/Go_(pro…

> I'm not following you at all.

Not even a tiny little bit? Really?

First of all, apologies for my boneheaded mistake, but let me try to see if I can show you the problem. If everything, everything there is, was named "Tom," you can see how it might get confusing determining just what is being talked about. That is hyperbole, but it should illuminate why it is ambiguous to call two things by the same name, but it is even more so when these two things with the same name operate in the same space.

But wait, you say, they are entirely different and unrelated! You think no one will be confused, because one Carbon is a programming language possibly based on C++ and the other is a C programming language API. Totally different, huh?

In fact, they're in the same space, programming. One Carbon is a language, the other a application programming interface for another programming language. They're also more or less dealing with the same programming language. I realize C is not C++, but without C there would be no C++, so they are very strongly related, along with ObjC. Fundamentally, these languages are all C, the newer ones using the same syntax but with advanced features not found in C. Still C, if we're being handwavy, and we definitely are.

So now, whenever someone mentions Carbon somewhere, like, "use Carbon!" That will be ambiguous due to this developer's unfortunate lack of nomenclature creativity.

Does that help at all to reveal why a new programming language based on C++ should probably chose a unique name rather than recycle a name that is still in use to refer to a C API? Since Apple already chose Carbon for their C API, and since it is so well established, even if it is no longer used, and since it is just not that old, and it when it was current, it was everywhere Apple, then it takes priority. So the arbitrary name this developer chose will inherently cause confusion, inevitably, because another Carbon already exists in the programming space.

Why not call it "Centigrade?" Or "lightspeed?" Because calling a C++-based language "Carbon" because it is based on C++ is not remotely as clever as Apple calling their C API Carbon because C is the symbol for Carbon, and not C++, which itself is a great name for a programminglanguage because it will never be confused with anything else, because afaik nothing other than C++ is called C++.

Let me know if you need more explanation why Carbon is an unfortunate name for anything new in the programming world. If it was, idk, the name of a publishing company or something, it wouldn't matter. It only matters because these things are in the same space.

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

#380

Post by twoodfin »

vitno wrote: post #9

It's not immediately obvious from this page and GitHub org, but this is a Google led project. It's led by Chandler and the c++ toolchain team. I have no idea of it's endgoals or how open to non-Google ideas it will be.

The primary goal is clear from the P2137 document: Performance. There are optimizations both in the standard library and the language that the C++ committee will either adopt too slowly for Google’s needs or not at all.
Post reply on HN