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

101–110 of 243 posts

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

#101

Post by sudosysgen »

pkolaczk wrote: post #25
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.

Instead Rust has a borrow checker, procedural macros of different types, half a parallel language when using unsafe, etc...

And by the way, Rust does have pointer arithmetic.

It's not clear to me that either is simpler or easier. The big point of Rust is really memory safety, not ease of use or simplicity.

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

#102

Post by stonemetal12 »

ho_schi wrote: post #30

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

Looks fairly slow to me, C# is already on V10. C# isn't nearly as old, and has had much larger features added.

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

#103

Post by gpderetta »

unrealhoang wrote: post #33
hbossy wrote: post #5

var r : i32; How is this any better than int32_t r; ? all I see is additional, unnecessary keyword to type.

To avoid https://cdecl.org/ is good reason enough. Enjoy parsing middle-out, I’ll take a keyword any day of the week. On that note, is there any recently created programming language decided to go with that type before name?

prefixing with the type wouldn't require middle-out though.

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

#104

Post by stonemetal12 »

flumpcakes wrote: post #74
miohtama wrote: post #2

It’s clear that the value promise of Carbon is to make it attractive to port existing C++ applications to it. But how this is accomplished, article does not go into detail in this. Is there going to be ABI compatibility with C++? What are the features that make Carbon a better porting target than Rust?

Rust will require a complete re-write or extensive work implementing a C-like interface for your C++ API. Carbon will be able to use C++ classes natively, including calling methods etc. I think Carbon will be a much better choice for extending a C++ project. Rust might be a good choice if you are able to start from scratch or the project has C bindings.

How did the firefox team handle it? They have moved parts to Rust while the rest is still C++.

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

#105

Post by olodus »

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?

Yeah I don't really understand that either. I have never written D myself but everyone I've looked at the language it has seemed to have sensible solutions to things and I would much rather write that than C++.

I guess it hasn't as good interoperability with existing C++ as Carbon is aiming for (I don't think, could be wrong) and wouldn't give Google as much control of it as it probably will have over Carbon.

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

#106

Post by adamrezich »

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…

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

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

#107

Post by tormeh »

flumpcakes wrote: post #74
miohtama wrote: post #2

It’s clear that the value promise of Carbon is to make it attractive to port existing C++ applications to it. But how this is accomplished, article does not go into detail in this. Is there going to be ABI compatibility with C++? What are the features that make Carbon a better porting target than Rust?

Rust will require a complete re-write or extensive work implementing a C-like interface for your C++ API. Carbon will be able to use C++ classes natively, including calling methods etc. I think Carbon will be a much better choice for extending a C++ project. Rust might be a good choice if you are able to start from scratch or the project has C bindings.

Wasn’t https://cxx.rs/ supposed to make writing C-bindings unnecessary?

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

#108

Post by jollybean »

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…

Because Rust is equally a terrible language to work with unless you're aligned with the objectives of the languages.

Go is a bigger language than Rust, it's not surprising to see people move over, that doesn't mean it's going to get used.

You're also vastly underestimating the number of people who otherwise like C++ and wish there was just an easier to use version.

For example - if 'Magic Carbon' somehow got rid of the ugly parts of C++, integrated smart pointers into the syntax, made the tooling, builds more robust, and somehow made it possible to integrate with C/C++, it'd be my new favourite language.

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

#109

Post by [deleted] »

stonemetal12 wrote: post #102
ho_schi wrote: post #30

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

Looks fairly slow to me, C# is already on V10. C# isn't nearly as old, and has had much larger features added.

[deleted]

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

#110

Post by wgjordan »

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…

> Why try to compete with Rust while not really being a better Rust?

The article addresses this directly and is clear that Carbon is not designed to 'compete with Rust', and instead targets a much narrower use-case:

> Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust.

I don't have a large C++ codebase to maintain so I don't currently have any use for Carbon, but I could see it being interesting for those who do.

Post reply on HN