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

181–190 of 521 posts

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

#181

Post by Koshkin »

Kranar wrote: post #143
fluoridation wrote: post #91

Earlier quoted context omitted.

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

Indeed, "vector" appears to be relatively recent terminology, it has been "array" since the dawn of programming. But it's too late now, and we already have the std::array anyway...

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

#182

Post by anon25783 »

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.

looks like Rust mixed with Go

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

#183

Post by summerlight »

skavi wrote: post #175
compiler-guy wrote: post #137

Earlier quoted context omitted.

The major usecase for Carbon is to advance Google's internal, multi-billion line, C++ codebase. As nice as a greenfield language with a clean ffi would be, "extremely close ties to C++" is Carbon's primary benefit.

sorry for nitpicking what is likely intentional exaggeration, but multi billion can’t be anywhere near accurate, right?

It's a bit of an exaggeration, but it's close. If you count all Google's C++ code base (google3 + open source) it's fairly close to one billion. If you count regardless of language, I believe it's ~3B.

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

#184

Post by fractalb »

chandlerc1024 wrote: post #69
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…

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

Tangent. Absolutely loved your CPPCON talks. Thanks.

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

#185

Post by fancyfredbot »

mihaigalos wrote: post #153
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

As far as I'm concerned, C++ is there for legacy purposes only. There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS. Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster). As even the Linux kernel is slowly transitioning to using Rust [2…

My impression as a CS grad is that very few computer science courses require you to learn C++.

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

#186

Post by saagarjha »

skavi wrote: post #175
compiler-guy wrote: post #137

Earlier quoted context omitted.

The major usecase for Carbon is to advance Google's internal, multi-billion line, C++ codebase. As nice as a greenfield language with a clean ffi would be, "extremely close ties to C++" is Carbon's primary benefit.

sorry for nitpicking what is likely intentional exaggeration, but multi billion can’t be anywhere near accurate, right?

No, Google really has that much code. Some of it is probably machine generated but it's definitely in the billions of lines.

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

#187

Post by flohofwoe »

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.

I'd say the syntax looks like most other modern languages, not just Rust.

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

#188

Post by compiler-guy »

skavi wrote: post #175
compiler-guy wrote: post #137

Earlier quoted context omitted.

The major usecase for Carbon is to advance Google's internal, multi-billion line, C++ codebase. As nice as a greenfield language with a clean ffi would be, "extremely close ties to C++" is Carbon's primary benefit.

sorry for nitpicking what is likely intentional exaggeration, but multi billion can’t be anywhere near accurate, right?

There are many billions of lines in Google's monorepo[1], summing well over 80 terrabytes of data. The paper below is from 2016, and the repo has only gotten bigger since then.

Exactly how many of them are C++ is not disclosed, as far as I know. But it is public knowledge that C++ is the biggest of Google's primary languages (C++, Java, Go, Python, Javascript, and so on).

https://research.google/pubs/pub45424/

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

#190

Post by Koshkin »

yakubin wrote: post #119
fluoridation wrote: post #91

Earlier quoted context omitted.

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

Worse, they have been calling the location of a pointer to a subroutine that handles an interrupt a "vector" - the word which was originally used to refer to the entire set of such locations. (Curiously, this usage is similar to how the word "sector" is used to refer to a physical record on a disk - simply because it usually comes last in the coordinate triple (cylinder, track, sector). This would be like calling a point in the 3-dimensional space a "Z".)
Post reply on HN