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

91–100 of 521 posts

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

#91

Post by fluoridation »

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.

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.

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

#92

Post by dangets »

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…

A blog post by Roman Elizarov (Kotlin designer) on the observation of types following the variable name [1]. It mostly states that having consistent length prefixes (fn, val/var) makes the code more readable than arbitrarily long type identifiers (in the eye of the beholder). Not scientific, but interesting.

[1] https://elizarov.medium.com/types-are-moving-to-the-right-22...

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

#93

Post by kllrnohj »

zozbot234 wrote: post #82
kllrnohj wrote: post #62

Earlier quoted context omitted.

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.

> Also D objects have a different lifetimes & requirements, which complicates things Does Carbon actually solve these issues, though? It would be great if it did, but they don't list complete interop w/ C++ as an actual goal of theirs, only enough to make it practically viable for development.

Carbon's memory model is compatible with C++'s[1], so where would you foresee complications? D could have been so much better here if it just hadn't chosen to be a GC'd language. That single choice pretty much kills any easy interop.

1: "For example, C++ and Carbon will use the same memory model." https://github.com/carbon-language/carbon-lang/tree/trunk/do...

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

#94

Post by zozbot234 »

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.

> The syntax looks a lot like Rust, though. I'm surprised they made such a break

Convergent evolution. Rusty syntax is pretty close to what you get if you want to make a language look broadly similar to C/C++ while avoiding pathological and/or computationally difficult parsing.

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

#95

Post by vitno »

chandlerc1024 wrote: post #79
vitno wrote: post #16

Earlier quoted context omitted.

The governance of the project is not immediately clear to me, and I have to assume that the Google team is working in good faith. That team cares a lot about C++ and its future. They are obviously aware of this stigma. I also think that Google is pretty bad at open source governance though :/ Disclosure: Former Google engineer who worked sorta adjacent to some of those people.

FWIW, our governance structure is here: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

Hahaha, I really like the "painter" terminology. A+

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

#96

Post by zozbot234 »

kllrnohj wrote: post #93
zozbot234 wrote: post #82

Earlier quoted context omitted.

> Also D objects have a different lifetimes & requirements, which complicates things Does Carbon actually solve these issues, though? It would be great if it did, but they don't list complete interop w/ C++ as an actual goal of theirs, only enough to make it practically viable for development.

Carbon's memory model is compatible with C++'s[1], so where would you foresee complications? D could have been so much better here if it just hadn't chosen to be a GC'd language. That single choice pretty much kills any easy interop. 1: "For example, C++ and Carbon will use the same memory model." https://github.com/carbon-language/carbon-lang/tree/trunk/do...

AIUI, you don't need to use D with a garbage collector. It can be disabled.

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

#97

Post by imachine1980_ »

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.

Rust is like c++ but only the new way to doing c++ is huge rust is like subset of c++ and ownership model. I thing is the right way c++ is harder than rust only because is so bloated. Carbon seams less bloated "fork" of c++ whit only the new way of doing things, but allow you full interoperability whit all c++, instead of partial and i don't see ownership, i thing is taxing mentally (worth or not depends). if i work in c++ i totally will use this.

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

#98

Post by dixego »

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…

From the "Why build Carbon?" section:

> The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax.

That last part seems to imply that the authors don't consider C++ syntax to be a good foundation for a modern successor language, so they chose to change it. As to why change it in a Rust-like direction I'd imagine that it's both because it's what fashionable at the time and possibly to attract people who are already familiar with that style.

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

#99

Post by slt2021 »

cnity wrote: post #18
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.

True, though in OP's defense I don't know if I've ever seen a language refer to a growing list of entries as an "array".

Object Pascal's arrays are dynamic.

var kek: array of int;

setlength(kek, 666); // kek is now int[666]

setlength(kek, 1337); // kek is now int[1337]

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

#100

Post by dleslie »

imaltont wrote: post #84
dleslie wrote: post #24

Earlier quoted context omitted.

Interestingly enough, Chicken Scheme has a library that allows for interop with C++ to this degree: http://wiki.call-cc.org/eggref/5/bind#c-notes

I believe Clasp has a pretty good C++ interface as well for Common Lisp.

It looks superior to Chicken's, albeit requiring more initial configuration:

https://clasp-developers.github.io/clbind-doc.html

Post reply on HN