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

111–120 of 521 posts

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

#111

Post by usrusr »

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.

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 perception (and mine) that rust is about to become the new default for "true native" is perfectly consistent with this, a language for the rust generation for when they have to deal with the c++ legacy. A legacy that won't be going away any time soon. I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't", my perception (from a quick glance at the site) is that they are fully aware of the limitations of the niche they have so clearly staked out.

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

#112

Post by saagarjha »

mrits wrote: post #75
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…

Designing a language to interop well with a single language is short sighted in my opinion. I want a clean ffi that I know will be able to iterop with Swift, Typescript, C#, C++, C, python etc... In my current project I'm currently using Rust/protobuff to do all of this and it rarely gets in my way of how I want to do things.

This language has “zero-cost” with C and C++, “minimal cost” with anything else that is compatible with those ABIs, and “moderate cost” with everything else via protobufs :P

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

#113

Post by saagarjha »

lenkite wrote: post #89
mepian wrote: post #19

It's a shame a stable ABI is declared as one of the non-goals, C++ is painful enough to integrate with other languages.

A stable ABI can effectively kill a language. https://cor3ntin.github.io/posts/abi/

(At Google, it’s definitely useful to others.)

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

#114

Post by cyber_kinetist »

outside1234 wrote: post #86

We already have this with an open foundation: Rust No thanks

They have an entire FAQ subsection pointing out some practical reasons why one might choose Carbon instead of Rust.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

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

#115

Post by Kranar »

mrits wrote: post #75
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…

Designing a language to interop well with a single language is short sighted in my opinion. I want a clean ffi that I know will be able to iterop with Swift, Typescript, C#, C++, C, python etc... In my current project I'm currently using Rust/protobuff to do all of this and it rarely gets in my way of how I want to do things.

Many long living languages are those that are source compatible with a single language. C++, Objective-C, TypeScript come to mind.

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

#116

Post by imaltont »

dleslie wrote: post #100
imaltont wrote: post #84

Earlier quoted context omitted.

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

Well, they are different languages made for different things. Clasp was specifically made because the author had a bunch of C++ code for his research projects, but wanted something more high level/simpler to implement things in. He landed on Common Lisp but none of the implementations had good C++ interop, so he made his own. Can recommend Christian Schafmeister's (creator of clasp) talks on it, it's interesting stuff. In particular his talk on an LLVM Conference.

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

#117

Post by Erlangen »

saghm wrote: post #67
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…

> 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; }`

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

#118

Post by xigoi »

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.

A vector can't change its size or contain things that aren't elements of a field. A std::vector can.

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

#119

Post by yakubin »

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.

It's not. Vectors can be added together and multiplied by scalars. That they are often represented as tuples of coefficients is just notation, doesn't matter for the notion of vectors, and vice versa: a tuple is not necessarily a vector.

1. std::vector doesn't have a fixed dimensionality, as would a mathematical vector. A fixed-length array actually makes more sense as a vector.

2. It doesn't provide the operations of addition and multiplication by scalars out-of-the-box (though you can whip up your own). Moreover, in general those operations wouldn't make sense for the elements which can be stored in a std::vector. E.g. neither multiplying bank account numbers by scalars, nor adding two bank account numbers make any sense. It would be good if you modelled them with types which don't allow those operations. Yet storing them in a std::vector makes perfect sense. But std::vector (or tuple) of bank account numbers is not a vector.

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

#120

Post by dymk »

zozbot234 wrote: post #96
kllrnohj wrote: post #93

Earlier quoted context omitted.

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.

The D standard library is heavily tied to the GC. If you want to avoid the GC, you'd have to give up the standard library, and if you do that, you have to give up most of the D ecosystem.

As far as I can tell, there hasn't been progress in untying the stdlib from the GC - https://github.com/dlang/projects/issues/56

Post reply on HN