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

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

#141

Post by compiler-guy » Tue, Jul 19, 2022, 4:39 PM UTC

gpderetta wrote: post #104

brandmeyer wrote: post #46

Earlier quoted context omitted.

> A key example of this is the committee's struggle to converge on a clear set of high-level and long-term goals and priorities aligned with ours [ https://wg21.link/p2137 ]. I was frankly shocked by that goals and priorities document. The non-goals section reads like an open declaration of war against anyone whose use cases for C++ differ from GOOG and NVDA. My interpretation of Carbon is that since GOOG failed to t…

I don't necessarily agree with all their design goals, but it is unfortunately true that getting a large coherent change through the C++ committe is an herculean task. The language ends up doing a random walk via small steps through the design space without a coherent long term vision, because nothing else is feasible. Implementing a coherent vision might lead to a better language even if most stakeholders might disa…

There are weird governance issues with the C++ committee too. Acceptance or rejection of a feature can depend on which reps just happen to show up that day.

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

#142

Post by saghm » Tue, Jul 19, 2022, 4:40 PM UTC

Erlangen wrote: post #117

saghm wrote: post #67

Earlier quoted context omitted.

> since they're heavily influcened by the Rust syntax, why not just learn Rust instead Interestingly, when looking at their code samples, the vibe I get is more "Go++". Using `var` for variable declarations, letter casing for visibility, explicit returns even at the end of functions, using the "package" keyword for namespacing, etc. I do see some superficial syntactic similarity to Rust, like using `fn` for functions…

> like using `fn` for functions and `->` to annotate return types `->` syntax is included in C++11 standard, named "trailing return type", but its adoption seems to be very slow. `auto f() -> int { return 42; }`

Interesting, I didn't know that!

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

#143

Post by Kranar » Tue, Jul 19, 2022, 4:41 PM UTC

fluoridation wrote: post #91

yakubin wrote: post #7

Earlier quoted context omitted.

It's std::vector that was weirdly named. In plenty of codebases "Vector", particularly gamedev and scientific, will mean the mathematical object with that name. Other languages don't need to replicate this mistake.

An std::vector is a vector in the mathematical sense, though. It's a homogeneous tuple. It's just that using an std::vector of std::vectors to store a list of points would be inefficient.

No it's not and even Stepanov, the person who gave it its name, has admitted it was a mistake:

Link to lecture by Stepanov: https://www.youtube.com/watch?v=etZgaSjzqlU

Furthermore in his book "From Mathematics to Generic Programming", Stepanov says that if he could change its name, he'd have named it "array".

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

#144

Post by UncleMeat » Tue, Jul 19, 2022, 4:41 PM UTC

Sebb767 wrote: post #72

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…

The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I'm not too confident that Rust-but-with-OO is enough of a selling point.

Syntax migration is easy. It is the semantic migration that is hard.

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

#145

Post by formerly_proven » Tue, Jul 19, 2022, 4:42 PM UTC

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…

> In otherwords, what carbon can do that Rust can't do, is take a C++ class with a `foo` method and call that method. Or create a class with a `foo` method and call that method from C++. Probably one of the biggest hurdles to get over in C++ interopt. Most don't do that, instead you'd make a C function binding and struct and move data/invoke functions through that.

https://cxx.rs

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

#146

Post by mlinksva » Tue, Jul 19, 2022, 4:42 PM UTC

I don't see the name explained anywhere in the excellent FAQ and other documents, but I wonder if it a play on Rust/Oxidize/Oxidization -> Carbon/Carbonize/Carbonization.

Only mention of those terms seems to be https://github.com/carbon-language/carbon-lang/issues/505 which seems like weak evidence against naming conjecture.

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

#147

Post by compiler-guy » Tue, Jul 19, 2022, 4:42 PM UTC

danjoredd wrote: post #140

Don't create a programming language to kill another language. That never works. Create a language that fulfills a specific purpose.

Carbon is intended to kill C++ in just the same way as C++ is designed to kill C, Kotlin is designed to kill Java, and Dart is designed to kill Javascript.

Which is to say, "Not at all".

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

#148

Post by adastra22 » Tue, Jul 19, 2022, 4:43 PM UTC

jeltz wrote: post #61

rvz wrote: post #49

Earlier quoted context omitted.

I still haven't seen a cross-platform production level GUI app written in Rust. All the time, it is C++ these companies use for these apps, especially having millions of users and generating multi-millions or hundreds of millions of dollars.

Many cross platform GUI apps have been written in C, JS and Java too. The ability to write GUI apps does not really seem that unique to C++.

That’s not the claim being made.

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

#149

Post by sudosysgen » Tue, Jul 19, 2022, 4:44 PM UTC

zozbot234 wrote: post #123

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…

My guess is that it's pretty much all about 2. They say explicitly in their FAQ that you should be using Rust, or any other well-established language, if not constrained by the need for deep, complex interop with C++ code bases. They're not positioning this as a "more approachable" alternative to Rust, only as one that sticks closer to existing C/C++ coding patterns.

To be fair, for many many many people there is a requirement for deep, complex interop with C++. Even if you're getting started on a new project being able to easily leverage the C++ ecosystem could make or break it.

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

#150

Post by fsloth » Tue, Jul 19, 2022, 4:45 PM UTC

mempko wrote: post #130

usrusr wrote: post #111

Earlier quoted context omitted.

Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach. Your…

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

Regarding C++. IMHO - it’s not getting intrinsically better. More complex. Easy things become a bit less verbose, but the hardest things remain as hard and the compiler is as unhelpful as before.

I agree C++11 and it’s successors are sugaring the language to be a lot nicer but fundamentally nothing has changed.

Rust is fundamentally better in it’s compiler warnings (they are actually helpful), and contains specific solutions to the things that are hard and bite you in C++.

C++ is not going away and it’s my main professional language but Rust does have features that are better.