Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Launches Carbon, an Experimental Replacement for C++

thenewstack.io

Post reply on HN
Print view View original

211–220 of 243 posts

Re: Google Launches Carbon, an Experimental Replacement for C++

#211

Post by flakiness »

jandrewrogers wrote: post #154
robmccoll wrote: post #19

I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is exp…

It is difficult to tell sometimes due to its religious backward compatibility, but C++ has been becoming significantly less complex over time. I have a large C++ code base (originally hundreds of thousands LoC) that I aggressively modernize, essentially rewriting it idiomatically in new versions of C++. It was originally written in C++0x/C++11, rewritten in C++17, and is currently being rewritten in C++20. You can ba…

> Hence the proliferation of non-standard "standard" libraries for C++.

Any examples for this? My knowledge stopped at boost and I guess there are more.

Re: Google Launches Carbon, an Experimental Replacement for C++

#212

Post by pornel »

BitwiseFool wrote: post #137
dzonga wrote: post #23

Earlier quoted context omitted.

to me that's the greatest benefit of C++ and hence why it's so successful. it's kitchen sink language. choose what features you want. choose your own style. you wanna do OOP | DOP suit yourself. that versatility is why C++ is unmatched in terms of where it's deployed.

Isn't the 'kitchen sink' approach what ended up causing Perl to fade from relevance? I am only casually aware of this, and I may be totally misremembering things, but Perl used to be seen as a swiss army chainsaw but people eventually came to realize that maintenance was a nightmare.

From my webby perspective mod_php has been the Perl killer, and PHP isn’t known for being lean either.

Re: Google Launches Carbon, an Experimental Replacement for C++

#213

Post by iamcreasy »

squarefoot wrote: post #59

Speaking not from direct experience, having barely touched C++ in the past and never touched D yet, but I've read many paint it as the natural successor, so why not D?

I've heard Jonathan Blow say D is still too much like C++ in one of the initial video on Jai.

Re: Google Launches Carbon, an Experimental Replacement for C++

#214

Post by usefulcat »

rajman187 wrote: post #96

While I have not had time to check this out, more generally whenever I read “Google launches…” I wonder how long until it makes it into the ever-growing graveyard? [1] https://killedbygoogle.com/ [2] https://gcemetery.co/

On one hand, fair point. OTOH, last I heard, golang is still very much alive.

Re: Google Launches Carbon, an Experimental Replacement for C++

#215

Post by quietbritishjim »

gpderetta wrote: post #163
quietbritishjim wrote: post #148

Earlier quoted context omitted.

Interesting - that prevents one of the two cases. Given fn(const Foo&) (or fn(Foo&)), your implementation would stop fn(move(x)) from compiling. But given fn(Foo) and const Foo x, your implementation would still allow fn(move(x)) to compile and perform a copy.

The Foo& case won't compile. Const foo& will as temporaries can bind to const references; this is desirable and x is still moved from. The plain Foo case won't do any copies because of NRVO and temporary elision (both optimizations are now guaranteed by the standard); again x will be moved from. The upside of this implementation is that x is always moved from. The downside is that sometimes more objects are created (…

> The Foo& case won't compile. Const foo& will [compile]

Not true. Both Foo& [1] and const Foo& [2] parameter types fail to compile (in gcc 8.5, I also tried gcc 10 with same result).

Bizarrely, in more modern compilers, including gcc 11, both Foo& [3] and const Foo& [4] do compile, even with the language version forced to C++11. I'm very curious to know why; presumably there's some defect report that got retroactively applied to all standards, but I can't find anything relevant. In any case, this illustrates how cryptic the C++ rvalue rules are.

[1] https://godbolt.org/z/97Yse4jWY

[2] https://godbolt.org/z/Gsj83zes6

[3] https://godbolt.org/z/xWhG9cxKn

[4] https://godbolt.org/z/xadn7Txh4

> Const foo& will as temporaries can bind to const references; this is desirable and x is still moved from.

Well that (it's desirable) is your opinion! In my view, in an ideal world, f(move(x)) would not mean there is at least one move... it would mean there are at most zero copies.

Re: Google Launches Carbon, an Experimental Replacement for C++

#216

Post by gpderetta »

quietbritishjim wrote: post #215
gpderetta wrote: post #163

Earlier quoted context omitted.

The Foo& case won't compile. Const foo& will as temporaries can bind to const references; this is desirable and x is still moved from. The plain Foo case won't do any copies because of NRVO and temporary elision (both optimizations are now guaranteed by the standard); again x will be moved from. The upside of this implementation is that x is always moved from. The downside is that sometimes more objects are created (…

> The Foo& case won't compile. Const foo& will [compile] Not true. Both Foo& [1] and const Foo& [2] parameter types fail to compile (in gcc 8.5, I also tried gcc 10 with same result). Bizarrely, in more modern compilers, including gcc 11, both Foo& [3] and const Foo& [4] do compile, even with the language version forced to C++11. I'm very curious to know why; presumably there's some defect report that got retroactive…

It doesn't compile because the code is wrong :).

I forgot remove reference for the T in the result type and in the return statement.

Interestingly it compiles with gcc-12 for some reason.

In generic code you do want to copy if T is not movable (for example when implementing a container). The annoying thing with the existing std move is that it might or might not move from the x depending on the implementation of the sink. This implementation will always move from if x is movable.

Different tradeoffs.

Now can we make a move with your requirements (only move no copy?) I think so. Let me think about it.

Re: Google Launches Carbon, an Experimental Replacement for C++

#217

Post by nicoburns »

nottorp wrote: post #135
nicoburns wrote: post #31

Earlier quoted context omitted.

I can't see details of the Carbon syntax for pointer, array and function types, but this is where Rust's type syntax really excels compared to the C++ style. let foo : & fn(&[MyType], i32) -> String = ... (a reference to a function that takes a slice and a 32bit signed integer as arguments and returns a string) is dramatically simpler than the C/C++ equivalent. More subjectively, I find `var` or equivalent makes code…

It's definitely as hard to read as C++ though.

I really disagree. Specifically when you have types nested within one another the complexity doesn't increase much. Whereas with C++ style declaration it quickly becomes type soup.

Re: Google Launches Carbon, an Experimental Replacement for C++

#218

Post by baobob »

pipeline_peak wrote: post #171
hiq wrote: post #52

Earlier quoted context omitted.

If they manage to make Carbon highly compatible with C++ (which is one of the design goals IIUC), then a C++/Rust compatibility layer should work fine with Carbon/Rust, or am I missing something? That's a big "if" of course, and time will tell whether they manage to pull it off, but at least that seems to be where they want to go.

Rust is already in production, I don’t think they take a different approach to compatibility.

From experience binding some Rust and C++ is not a trivial task. The introduction of Rust ownership and lifetimes alone means this always involves new design, even just to provide something approaching a 1:1 mapping to an existing API. True 1:1 mappings at least in my experience simply aren't possible, there is always some contortion required to reduce the freedom+unsafety exported by C

Re: Google Launches Carbon, an Experimental Replacement for C++

#220

Post by tekknik »

ladberg wrote: post #114
tekknik wrote: post #70

Earlier quoted context omitted.

knowing neither of these languages i’d rather it be labeled something more clear as neither one of those screams immutable to me. the immutable variant should use the ‘const’ keyword instead.

To me `var` by definition means mutable and `let` sounds like you're laying out a constant in a proof, so I'd say both are pretty clear.

they both sound exactly the same to me, let sounding like an alias for var.

also programs aren’t proofs so we certainly shouldn’t name keywords after them

Post reply on HN