There's already a successor to C++. It's called D.
How does D's safety compare to Rust and Carbon?
Google Launches Carbon, an Experimental Replacement for C++
231–240 of 243 posts
Re: Google Launches Carbon, an Experimental Replacement for C++
#232wasn't go supposed to be a replacement for C++?
No. It's more like a fast Python.
Re: Google Launches Carbon, an Experimental Replacement for C++
#233Why are new languages always putting the type on the right :(
Like Pascal, Modula-2 and Oberon I guess.
Re: Google Launches Carbon, an Experimental Replacement for C++
#234So, is Carbon supposed to replace Go as well?
No. Different targets.
Re: Google Launches Carbon, an Experimental Replacement for C++
#235var r : i32; How is this any better than int32_t r; ? all I see is additional, unnecessary keyword to type.
I think by using `var` keyword you have the potential to inherit the type without changing too much the syntax, in rust you could omit the type if the compiler can inherit the type, that saves you a lot of typing in the future, but you could argue that it makes harder to read the source code without any tool.
The word you wanted was "infer" not "inherit"
For example "if the compiler can inherit the type" should read "if the compiler can infer the type".
Re: Google Launches Carbon, an Experimental Replacement for C++
#236Not a C++ programmer, but I'd like to ask: Are Carbon's goals for interop here sufficient for most libraries and frameworks, or will bridge code be required in most cases? I see this about exceptions, for instance: "Carbon may not provide seamless interoperability support for C++ exceptions. For example, translating C++ exceptions to or from Carbon errors might require annotations or bridge code, and those translatio…
I am guessing that this is less of a concern for Google. Per Google's C++ style guide : "We do not use C++ exceptions."
So they are already not using that feature in their C++ code today.
https://google.github.io/styleguide/cppguide.html#Exceptions
Re: Google Launches Carbon, an Experimental Replacement for C++
#237Not a C++ programmer, but I'd like to ask: Are Carbon's goals for interop here sufficient for most libraries and frameworks, or will bridge code be required in most cases? I see this about exceptions, for instance: "Carbon may not provide seamless interoperability support for C++ exceptions. For example, translating C++ exceptions to or from Carbon errors might require annotations or bridge code, and those translatio…
I am guessing that this is less of a concern for Google. Per Google's C++ style guide : "We do not use C++ exceptions." So they are already not using that feature in their C++ code today. https://google.github.io/styleguide/cppguide.html#Exceptions
That’s what I was getting at. I hope they get some real feedback from Nvidia, AMD, Intel, Qualcomm, etc before making something that is really only useful at Google.
Re: Google Launches Carbon, an Experimental Replacement for C++
#238Although it has both advantages, disadvantages and it's still being in an experiment phase, it's definitely a refreshing feeling in terms of syntax compared to C++. Tried with various different examples with different basic usage and wrote a detailed guide. If you want to get a quick feeling of how it looks like in terms of syntax, check this beginner tutorial.
Re: Google Launches Carbon, an Experimental Replacement for C++
#239I'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…
It is difficult to tell sometimes due to its religious backward compatibility, but C++ has been becoming significantly less complex over time. I have a large C++ code base (originally hundreds of thousands LoC) that I aggressively modernize, essentially rewriting it idiomatically in new versions of C++. It was originally written in C++0x/C++11, rewritten in C++17, and is currently being rewritten in C++20. You can ba…
> You can barely tell the code bases are related beyond being functionally similar.
Not sure if you've missed this, but this is a number one reason many consider C++ absurdly complex. To actually know C++ is to know many different similar languages based on the year the code was written. C++20 is very different than C++03 as noted. Now compare this with C, or Go, Java, etc. which in comparison have barely changed.
Re: Google Launches Carbon, an Experimental Replacement for C++
#240Does 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…
In Rust, types implement the Copy trait and the Drop (destructor) trait independently. Vec could easily implement Copy. It doesn't because copying a Vec requires an expensive heap allocation, which can surprise users when it happens implicitly.