Zig is to C as Carbon is to C++? The interop with existing C++ code, and ability to compile and understand existing code seems very similar.
Google Launches Carbon, an Experimental Replacement for C++
41–50 of 243 posts
Re: Google Launches Carbon, an Experimental Replacement for C++
#42> 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?
The "slow" isn't the performance of the application, but rather the ability to make changes to the language.
As it is, Google can't make changes to C++ that it wants in a timely manner (if at all). Having a C++g edition where there are slight changes to the language for the Google flavor rather than the latest standard makes things even worse.
From Google's perspective, the same can be said of Rust.
What Google does see is Swift where there are significant evolutionary changes to the language over the time.
So, Google has created their own language to fit into a similar space as C++ and allows them to make changes to the language at a much more rapid pace than the C++ standards committee would have.
My crystal ball says "this language will diverge further and further from where it started as Google changes it to solve Google Problems."
This shouldn't be a "Oh! Neat! Everyone start coding in Carbon - it's the next C++!" Yes, it's interesting in that there are some interesting ideas in it and refinement of ideas that aren't practical elsewhere. However, this is a language created to solve Google's problems - not the world's.
Re: Google Launches Carbon, an Experimental Replacement for C++
#43Does 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.
Re: Google Launches Carbon, an Experimental Replacement for C++
#44var 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…
Why isn't it
let foo : & (&[MyType] -> i32) -> String = ...
Re: Google Launches Carbon, an Experimental Replacement for C++
#45I'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.
In general, I think it's easy to conflate simplicity with ease. Ease is always a matter of context and what one is familiar with.
I agree that Rust is simpler than C++ and I think a lot of people mean that Rust isn't easier (up front). Given how new and different it can be, that makes sense.
Re: Google Launches Carbon, an Experimental Replacement for C++
#46Does 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 would need to add the rule that you can't move from a variable in only one branch of an if statement or from any sort of loop. Like a really primitive compile time borrow checker.
It seems to me that would be enough, but maybe I haven't thought it through properly, or maybe you'd end up having to copy a lot more often than you want to (or use optional half the time, which might defeat the point a bit).
Re: Google Launches Carbon, an Experimental Replacement for C++
#47var 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?
[deleted]
Re: Google Launches Carbon, an Experimental Replacement for C++
#48> 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.
Major upgrades that are fully backward compatible and therefore leave some significant performance and safety bugs untouched. What they mean by "slow evolution" is the increasing rigidity of core data structures and resistance to introducing replacements caused by the backwards compatibility promise. Adding new features is easier than changing existing ones.
This is both a strength and a weakness of C++. It's a very old language and it has been keeping that backwards compatibility promise for a very long time. The result is that certain portions of the language are effectively unchangeable as a result. This is the key thing that Rust's editions are trying avoid.
Re: Google Launches Carbon, an Experimental Replacement for C++
#49The example to me looks like C++ is still nicer, I don't get the hate on C++ but then again most of the native work I do is gamedev.
The benefit that C++ and Carbon can run together is a nice feature. It is like Objective-C++ (using ObjC + C++ together) or Swift/ObjC that worked well in gamedev as well when you needed to wire in a C/C++ game engine into iOS. For Android the NDK.
I think any C++ replacement has to be compatible with C++ but at that point isn't C++ still the root? C++ will never go away and it is actually a great language that is powerful. Then again I have spent lots of time in gamedev where that matters and most libs are going to be C/C++ for the foreseeable future.
Just learn C++.
You'll probably need to learn C++ to understand integrations with Carbon anyways. Carbon seems like yet another language you'll have to learn that is built on and tries to replace C++.
Fun fact: Fun fact: Objective-C was made in 1984, one year before C++ (1985).
Re: Google Launches Carbon, an Experimental Replacement for C++
#50Earlier quoted context omitted.
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.
C type declaration syntax isn't easy to read for humans, as demonstrated by demand for projects such as https://cdecl.org/>.