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

61–70 of 521 posts

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

#61

Post by jeltz »

rvz wrote: post #49
bestouff wrote: post #41

Earlier quoted context omitted.

I'm as tired as you by these cosmetic successors. But for my part I think C++ has already been replaced, and to great benefits. I couldn't thank the people building Rust enough.

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++.

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

#62

Post by kllrnohj »

zozbot234 wrote: post #31
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…

Isn't this one of the most prominent features in D? Sounds like they're trying for something very much like D, while starting closer to current C++.

D still requires you to write bindings, see https://dlang.org/spec/cpp_interface.html

Also D objects have a different lifetimes & requirements, which complicates things ( see https://dlang.org/spec/cpp_interface.html#lifetime-managemen... )

Carbon appears to be auto-generating bi-directional bindings, and since it has the same memory model has no such awkward interactions between non-GC'd and GC'd worlds like D does.

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

#63

Post by notriddle »

beeforpork wrote: post #50

Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give r…

It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first.

As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the lexer hack and most vexing parse aren't problems, but when the program isn't complete, parsing isolated fragments is impossible, and that limits the amount of useful tooling the language can have.

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

#64

Post by m4nu3l »

I had been thinking about something like this for a long time. There is just too much C++ code out there but C++ (despite many efforts by the standard committee) is still too verbose and hard to make sense of in many cases. So I thought "why not designing a new language that is compatible with C++?"

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

#65

Post by throw827474737 »

brandmeyer wrote: post #46
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.

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

> GOOG and NVDA

Why use these stock index abbrevs (or whatever they are) in this context here? GEEZ!

To the topic, it sounds a bit grumpy. If we look at languages and how many evolve... many suffer the phenomenon that they almost all are Turing complete, and try to gain concise (or simple understandable) expressiveness somehow, and then they try to not break compatibility too much to varying degrees - net result: they grow and grow where at one point they feel like too big, too much legacy dragged around (C++), the "one obvious way" lost (Python) when they cater for use case after use case.

Limiting can be good in that regard. So having key goals defined and not to cater to every small new usecase by someone is a valid attempt to not let this happen, so while I dislike Googles power, I wouldn't feel to bad with attempting this by anyone on their fresh language?!

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

#66

Post by kllrnohj »

yakubin wrote: post #7
dleslie wrote: post #3

I was interested and intrigued, but then: // A dynamically sized array, like `std::vector`. var circles: Array(Circle) = ({.r = 1.0}, {.r = 2.0}); Yegads, they've put effort into ensuring API and ABI compatibility with C++, but they've gone and decided to change the meaning of nouns for basic types?! Why, just why would introducing that obvious footgun be appealing? It raises the concern that the language is full of…

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.

Java's Vector looks around awkwardly, hoping everyone forgets it existed... ;)

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

#67

Post by saghm »

secondcoming wrote: post #43

Interesting. It will obviously take off _because Google_ but since they're heavily influcened by the Rust syntax, why not just learn Rust instead. They'll need to get it into Compiler Explorer so people can really look at codegen rather than porting small programs.

> 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 and `->` to annotate return types, using `:` for type annotations for variables, and semicolons seeming to be required at the end of lines, but overall it doesn't really _feel_ that much like Rust to me, I think due to how imperative it seems. Given the use of `class` and `let/var` seeming to be const versus mutable bindings, I'm wondering if the Rust resemblance is actually just transitive through more of a resemblance to Swift, although I don't know Swift well enough to know if this is an accurate explanation.

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

#68

Post by baxuz »

throw827474737 wrote: post #65
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…

> GOOG and NVDA Why use these stock index abbrevs (or whatever they are) in this context here? GEEZ! To the topic, it sounds a bit grumpy. If we look at languages and how many evolve... many suffer the phenomenon that they almost all are Turing complete, and try to gain concise (or simple understandable) expressiveness somehow, and then they try to not break compatibility too much to varying degrees - net result: the…

Oh so that's what they are.

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

#69

Post by chandlerc1024 »

brandmeyer wrote: post #46
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.

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

(one of the Carbon leads)

Success for the Carbon Language requires it to successfully be an independent and community driven project. We may not succeed (this really is an experiment), but we're working hard to engage broadly and early in large part because of this being such an important goal and priority for us.

Projects like this have to start somewhere, but can grow and become community endeavors. We are also already seeing strong interest from other companies and organizations in participating in this experiment.

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

#70

Post by zamalek »

donkarma wrote: post #56
zozbot234 wrote: post #31

Earlier quoted context omitted.

Isn't this one of the most prominent features in D? Sounds like they're trying for something very much like D, while starting closer to current C++.

D is closer to this than this rust rip-off

Like every braces language following C is a C rip-off?

Rusty syntax is objectively superior to almost everything else we've come up with, there's no reason it shouldn't be copied.

Post reply on HN