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

201–210 of 521 posts

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

#201

Post by the_duke »

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…

The README doesn't expand on what is probably the most challenging problem: how do you achieve effortless C++ interop without burdening Carbon with all the odd behaviour and memory safety / UB issues prevalent in C++?

In Rust for example, `unsafe {}` blocks are not just "local unsafety". They can freely operate on all memory, so they are infectious and are essentially a marker for "dangerous code below, be extra careful and audit lots".

But if all code can freely interoperate with C++, how do you improve upon C++, apart from relatively isolated features like a better generics system?

To what extend can a Carbon compiler that is deeply aware of C++ semantics mitigate the pitfalls?

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

#202

Post by ccbccccbbcccbb »

dvirsky wrote: post #200

Why did they go to such lengths to obscure the fact that it's a Google project? I heard about it back when I was a Googler so I knew immediately what it was, but otherwise it was very hard to find any indication that this is a Google led project.

Must be avoiding the stigma of the broken promise not to be evil.

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

#203

Post by Animats »

Can C++ be machine-translated to Carbon? That would be useful.

Translating C++ to Rust is too hard - the underlying data models are too different. What would be really useful would be something that intelligently translates pointer-based C++ code into a slice-based language. Every place there's an unsized array, something has to figure out how big it is and pass that info around. In the original program, that information had to be present in some form. The trick is finding it. That's probably not out of reach for a static analyzer today. Especially if machine learning is used to help find the usual idioms of C/C++. First find, then check.

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

#204

Post by fluoridation »

xigoi wrote: post #118
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.

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

Yes, you can have a vector of, say, naturals. I'm pretty sure you can even create a vector field out of vectors of non-reals.

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

#205

Post by dvirsky »

ccbccccbbcccbb wrote: post #202
dvirsky wrote: post #200

Why did they go to such lengths to obscure the fact that it's a Google project? I heard about it back when I was a Googler so I knew immediately what it was, but otherwise it was very hard to find any indication that this is a Google led project.

Must be avoiding the stigma of the broken promise not to be evil.

The thing is they have an excellent track record with runnig open source programming languages for over a decade. It's often claimed that Go succeeded only because it was sexy because it was Google. Why hide it here?

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

#206

Post by otabdeveloper4 »

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…

> Any serious new development today is done using more modern languages such as Rust

Uhm, no. Sorry, thanks for playing, try again.

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

#208

Post by nyanpasu64 »

c-cube wrote: post #138
notriddle wrote: post #63

Earlier quoted context omitted.

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…

The syntax `name: Type` is also friendlier to type inference as you generally have a token indicating a declaration. If you have `var x: Type = …` then you can just omit the type and let inference do its job. Even better, when you start having more complex patterns on the left-hand side of `=`, you can type annotate them as you want. Hypothetical syntax would be: var (x: f32, y, [z1,z2,z3]) = SomeExpression(); That's…

It would make sense if Carbon started allowing omitting ": Type", which they currently don't: https://github.com/carbon-language/carbon-lang/blob/trunk/do...

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

#209

Post by ArrayBoundCheck »

This is the 3rd language I know about that google created. I have no idea why they don't use rust with their C++ code base and I don't know why they made this instead of use zig which actually brings something new to the table.

Overall I don't see myself using this. 0/3 google

Post reply on HN