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

161–170 of 243 posts

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

#161

Post by Hasnep »

greenthrow wrote: post #140
adamrezich wrote: post #106

Earlier quoted context omitted.

…or we're just running out of names that are puns of "C" for C++ successor languages, so things that were deprecated a decade ago are now fair game?

Are you kidding? There's tons of other words that start with C. And why would it need to anyway? This trend of not putting any thought into what you name your language/framework/application is fairly new and shows serious laziness. Google's team should have done better. Naming things is hard but if you're going to make something worth people's time, it's worth spending a little more effort than they did.

The pun is that C is the chemical symbol for carbon.

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

#162

Post by kasabali »

fractalb wrote: post #155
BitwiseFool wrote: post #137

Earlier quoted context omitted.

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.

Perl faded away because there was an alternative (Python) and it was not a kitchen sink. For C++, there's no alternative at all. People have to bear with it.

Ironically Python is now fast approaching the kitchen sink status.

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

#163

Post by gpderetta »

quietbritishjim wrote: post #148
gpderetta wrote: post #80

Earlier quoted context omitted.

alternatively move should have been a real move: template T std::move(T&& t) { return T(static_cast ::type&&>(t)); } But it would have had performance implications.

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 (for example in the const&) than the pure cast case and can't always be reliably optimized out.

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

#164

Post by effingwewt »

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 love C++, being old school, and would love a decent successor but I'd never again touch anything with the google death-stamp.

How long before they pull the rug out, or do any of their other dirty shenanigans?

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

#165

Post by kaba0 »

sgjohnson wrote: post #73
DiabloD3 wrote: post #61

I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I kno…

> Swift implosion What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression

It became a kitchen sink language similarly to C++. For all the hate Java gets, they did tackle language development very well - wait a bit for other, niche languages to be your testing ground of new features, and only add what sticks. Swift literally has all the features you can find in today’s modern languages, and they have some inconsistent interactions with each other. Also, even this litany of features isn’t enough to make SwiftUI implementable only as a Swift library, it uses some specifics not available in the language otherwise.

And also, as most apple dev tools, it is the only modern language whose compiler failed under me (other than being slow as hell) - I have never gotten a type inference timed out error in other languages, even though it has been around for a time :D

As for growing a language, this is a must watch (bear with the presenter for the bit, you will soon understand why he talks strangely in the beginning): https://m.youtube.com/watch?v=_ahvzDzKdB0

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

#166

Post by ActorNightly »

Terretta wrote: post #66

How to make your replacement for a C language Google-able: name it after an API for a C language: Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Compare also keywords or key terms: Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need…

All i could think in reading your comment is this

https://xkcd.com/927/

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

#167

Post by ActorNightly »

qorrect wrote: post #111
cute_boi wrote: post #72

"The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux" I thought Linux was C only and Linus is actively hostile against cpp for some good reasons.

> I thought Linux was C only It won't be for long (Rust) https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linu... . But I don't expect C++ to be added.

Still a maybe, and they certainly won't be rewriting any core part of the linux in Rust.

While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.

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

#168

Post by brightball »

baobob wrote: post #28
brightball wrote: post #22

Earlier quoted context omitted.

I haven't used Rust much, but based on everything I've read it seems like if you need a better alternative to C or C++...Rust is pretty much the answer. Is that not accurate?

This comment and parent comment don't appear to have read the article. It's specifically targetting C++ compatibility, that means compatible threading model, memory model, ABI, type system, ... Rust has none of these. For every line of Rust code in the world, there are likely 10e3 - 100e3 lines of C++. You can either label it all "legacy code" and pretend your employer has the budget or time to rewrite it all, or you…

My mistake. Thank you for clarifying.

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

#169

Post by kps »

Hasnep wrote: post #161
greenthrow wrote: post #140

Earlier quoted context omitted.

Are you kidding? There's tons of other words that start with C. And why would it need to anyway? This trend of not putting any thought into what you name your language/framework/application is fairly new and shows serious laziness. Google's team should have done better. Naming things is hard but if you're going to make something worth people's time, it's worth spending a little more effort than they did.

The pun is that C is the chemical symbol for carbon.

But it's a C++ replacement, not a C replacement, so they should have named it Nitrogen.

Edit: it appears that Nitrogen and Phosphorus are already used by Lisp dialects.

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

#170

Post by tialaramex »

est31 wrote: post #55
quietbritishjim wrote: post #26

Does anyone know what the move / copy semantics are in Carbon? I can't figure it out from the docs (admittedly I have not looked hard at all). I would say the number one weakness of C++ is its model of copy by default and often by surprise. For example: f(std::move(x)) will copy x if x is const or f takes its value by const ref - rather than a compiler error as you might reasonably expect (if you don't know the C++ r…

> In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. Rust has implicit copies too, e.g. if you do: let v = 2u16; foo(v); then v is being copied. What Rust does not have is implicit deep copies. The auto-copying depends on the typ…

As Rust's documentation explains "... Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away"

What's important about Copy is that, since you said you want to permit Copy here, it's OK if Rust keeps both identical bit patterns alive after the bits are copied. Just keeping both alive is obviously better for trivial types like u32, but on modern hardware it's also true for somewhat more complicated types like &str (which is a pointer and a count) or SocketAddrV6 (an IPv6 address, a port number, flow label and so on).

Thus, in your example, v is being bit copied (at least notionally) in both cases to become the parameter of this foo function, but because v is Copy, we can nevertheless use v again on the next line, the bits in v are still alive. If v was not Copy (e.g. an owned String) then foo(v) consumes v, it's moved into foo and now it's gone, we can't access v on the next line.

The fact that foo(v) consumes v, is why core::mem::drop() is so trivial: https://doc.rust-lang.org/core/mem/fn.drop.html

Post reply on HN