Live data from Hacker News

Google Launches Carbon, an Experimental Replacement for C++

thenewstack.io

31–40 of 243 posts

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

#31
post #5

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

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 much easier to read, because you can scan for variable declarations much more easily. With C++ code, almost any token could be a variable declaration and you have to think about the type even if you wouldn't otherwise care about it. It also allows you to have inferred types without a separate auto keyword.

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

#32
post #23

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.

The more recent editions of C++ do seem to support this idea. Things are at least better than when the trade off was taking advantage of C++ features (and more C++ like) or performance (and more C-like C++). The problem that there are only a handful of people who could realistically claim to be experts in C++ has gotten worse over time as the language has expanded though. It's a language where you potentially have to train new C++ programmers that join your team in how your team uses C++.

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

#33
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?

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

#34
post #5

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

It is easier to parse. Less ambiguity with something like int32_t r(); what is that?

I would argue that convenience of users is more important than easy of parsing.

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

#35
post #28

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…

You didn't appear to read my comment, I'm talking about compatibility with Rust and all these other look alike languages.

Also your Vala comparison would imply this language compiles to C++.

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

#36
post #4

I’m a big fan of ‘var’ and ‘let’ in Swift. Easier to identify mutable vs immutable variables. I believe Carbon uses the same convention? https://github.com/carbon-language/carbon-lang Helps with quick auto-completion, and someday when I get to dictate code, fewer mistakes.

Nim also uses 'var' and 'let' for mutability. I like it as well.

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

#37
post #9

I've been seeing a lot of references to this across youtube, reddit etc for a new experimental language. Is google putting their full weight behind this like Go or is the virality just incidental?

Lots of people are interested in replacing C++. They disagree about what the replacement should be, to some extent because what they think is wrong with C++ can be quite different.

This is a team of people with serious C++ backgrounds, who explicitly are interested in this as a successor to C++. Some of these are people who worked on P2137 which is the "Goals and priorities" paper that the committee explicitly rejected for C++ 20, so they know what they think C++ should be, and they know WG21 doesn't want that, so if they do want it they're going to need a separate vehicle to get there.

Also they're far from finished, so there's the attraction that Carbon could be whatever it is you want, while something like Rust has decided what it is.

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

#38

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

Without the borrow checker, this "move-by-default, move is memcpy" semantics would break all hell loose. Dangling pointers/references would be everywhere. I like this part of Rust, but I'm not sure if it can work in a non-GC, no-borrow-checker language.

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

#40

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

While I intend to learn more Rust, compatibility with existing code is a big reason why I'm paying attention to Zig. It's not yet 1.0 and it's closer to C than C++.

However, because it's meant to compile and interop with both C and C++, I'm hopeful that it'll be an easier switch for more projects. It doesn't provide the safety checks that safe Rust does, but safe Rust requires a rewrite IIUC.

Post reply on HN