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

51–60 of 243 posts

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

#51

Post by nicoburns »

thomasahle wrote: post #44
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…

Why isn't it let foo : & (&[MyType] -> i32) -> String = ... Like in Haskell? Seems having both `fn` and `->` is unnecessary?

Well the syntax for declaring a function in Rust is:

    fn foo_bar(foo: &[MyType], bar: i32) -> String { ... }
so probably to match that.

I believe Haskell does something clever such that there is no difference between a function that takes two parameters, and a function that takes one parameter and returns a function that takes the second parameter. This isn't the case in Rust. Those would be distinct types and the latter would be called differently to the former. So I'm not sure that the Haskell syntax would work for Rust.

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

#52

Post by hiq »

pipeline_peak wrote: post #35
baobob wrote: post #28

Earlier quoted context omitted.

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

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.

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

#53

Post by tialaramex »

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.

The ability to ship new slightly incompatible versions of your "International Standard" every three years doesn't mean you're evolving quickly.

> Where C++11 and C++20 are huge major upgrades.

They seem significant by the standards of C++ but they're rather less impressive in the bigger picture.

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

#54

Post by jcranmer »

yakubin wrote: post #38
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. 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. Dan…

You don't need a full-on borrow-checker to make move-by-default safe.

If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.

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

#55

Post by est31 »

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 type and is only done for types that don't have a custom destructor, or to be more precise, implement the Copy trait. So a big array of integers gets copied (because it implements the Copy trait), but a Vec gets moved (because of its custom destructor there is no Copy trait implementation).

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

#56

Post by quietbritishjim »

jeffbee wrote: post #43
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…

The move situation would be less confusing to newcomers if they had called it what it really does, std::become_rvalue_reference or something.

I agree that it should have been named better (rvalue_cast might have worked) but that wouldn't have solved the core problem: Does f(std::become_rvalue_reference(x)) make a copy of x? It's more obvious that it might but I still lack the facility to make it cause a compile time error if it would (except changing x's class to disallow any copies at all).

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

#57

Post by jcranmer »

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…

> 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 read the documentation and had the very same question. My notes from the announcement thread had this line in it:

> * Not clear from the main design document is how the distinction--if any--between trivial/nontrivial copy/move types work. There appears to be an explicit move operator (with obvious syntax ~x), so support for nontrivial move or immovable is better than Rust already, but the avoidance of a NRVO setup still makes me wonder what the actual story is here.

Given that Carbon copies the signed-no-overflow/unsigned-may-overflow distinction from C/C++, it wouldn't surprise me if they also copy the move/copy rules from C++, as those are both rather fundamentally baked into C++ (which means you have to deal with it for automatic translation), even if they are pretty objectively confusing.

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

#58

Post by kirbyfan64sos »

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?

The official webisite (https://github.com/carbon-language/carbon-lang) goes into better detail, but the gist is that you can basically #include C++ libraries and use their APIs as-is, without needing to resort to unsafe blocks or having to write more idiomatic wrappers.

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

#60

Post by ur-whale »

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.

> all I see is additional, unnecessary keyword to type.

Not to mention the weird appearance of uppercase letters in function calls (Print ?)

Post reply on HN