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

21–30 of 243 posts

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

#21

Post by deadbeeves »

TinkersW wrote: post #14
melling wrote: post #8

Earlier quoted context omitted.

You type about the same number of characters. Now imagine you wanted to declare the value to be immutable.

Its 5 extra characters actually.. because any sensible C++ project has i32 etc defined. The type omission version isn't very useful, as this type of code is difficult to read later. Generally end up regretting using auto, and end up converting it to the actual type, except with iterators or nasty templates.

That hasn't been my experience, personally. In fact, sometimes I wish decltype was easier to use, to declare type dependencies.

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

#22

Post by brightball »

pipeline_peak wrote: post #11

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

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?

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

#23

Post by dzonga »

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…

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.

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

#24

Post by wyldfire »

pipeline_peak wrote: post #11

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

We have more than 5 C++-alike languages that are crawling around already. In some ways they have portions of mutual compatibility. But in practice this only matters if you decide to embrace the complexity of five different programming languages when building your software. It's already somewhat challenging for projects to manage assembly, C, and C++.

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

#25

Post by pkolaczk »

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…

> Rust isn't any more complex, but it's not radically simpler either.

Safe Rust doesn't have classes, inheritance, copy constructors, move constructors, header files, preprocessor, textual substitution macros, code executing before main(), exceptions, global variables, pointer arithmetic... Looks radically simpler to me.

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

#26

Post by quietbritishjim »

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++ reference model inside out).

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. I personally think that is all more useful than the borrow checker.

If Carbon has the same bizarre move/copy rules as C++ then the effort is wasted IMO.

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

#27

Post by russtrotter »

The first half of the article started to feel like the XKCD "15th standard" meme, but at the end, the more nuanced point was presented: If you're already using Rust, stick with Rust. Carbon is positioned as successor language for those with large C++ codebases difficult to convert to Rust.

Interesting tact, and at face value that concession might undermine adoption given that Rust has a big head start and not hinged to a corp with a well-earned reputation for killing projects.

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

#28

Post by baobob »

brightball wrote: post #22
pipeline_peak wrote: post #11

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

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 can find something in between writing new "legacy code", or throwing away your (for a company like Google) absolutely huge investment.

FWIW projects that build for interoperability have a much higher chance of long term success than those that don't. This is true for everything in software, not just programming languages. For this reason alone you can't easily compare Carbon and Rust. Carbon sounds something a little closer to Vala (C compatibility) than anything like Rust

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

#29

Post by threeseed »

brightball wrote: post #22
pipeline_peak wrote: post #11

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

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?

I have only dabbled in Rust but I found the interop situation to be less than ideal. Plenty of C/C++ libraries either don't have Rust wrappers at all or have been long abandoned.

I like the ability of Carbon to seamlessly integrate with existing C/C++ code and libraries.

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

#30

Post by ho_schi »

> Frustrated by the slow evolution

I think already the very first sentence is already wrong.

    1998 ISO/IEC 14882:1998 C++98
    2003 ISO/IEC 14882:2003 C++03
    2011 ISO/IEC 14882:2011 C++11
    2014 ISO/IEC 14882:2014 C++14
    2017 ISO/IEC 14882:2017 C++17
    2020 ISO/IEC 14882:2020 C++20
Where C++11 and C++20 are huge major upgrades.
Post reply on HN