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++ reference model inside out).
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.
If Carbon has the same bizarre move/copy rules as C++ then the effort is wasted IMO.
> 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).
As Rust's documentation explains "... Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away"
What's important about Copy is that, since you said you want to permit Copy here, it's OK if Rust keeps both identical bit patterns alive after the bits are copied. Just keeping both alive is obviously better for trivial types like u32, but on modern hardware it's also true for somewhat more complicated types like &str (which is a pointer and a count) or SocketAddrV6 (an IPv6 address, a port number, flow label and so on).
Thus, in your example, v is being bit copied (at least notionally) in both cases to become the parameter of this foo function, but because v is Copy, we can nevertheless use v again on the next line, the bits in v are still alive. If v was not Copy (e.g. an owned String) then foo(v) consumes v, it's moved into foo and now it's gone, we can't access v on the next line.
Sure, I knew about the Value trait but I thought it wasn't relevant for the general point (and I thought that sentence had too many parenthesised clarifications already!).
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.
> 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.
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.
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).
> 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.
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).
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 expressive, performant, and small while still general purpose is quite a challenge.
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.
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 barely tell the code bases are related beyond being functionally similar.
It is also important to separate C++ the language from its standard library.
As C++ the language has modernized, it has dramatically reduced the lines of code to express a given thing. And the more modern way of expressing the thing has stronger type safety, more flexibility, and better composability. Things that used to require a lot of template metaprogramming magic to pull off are now clean one-liners. Particularly in C++20, which is probably the biggest step-change since C++11, metaprogramming is simultaneously much more powerful and much more readable. A lot of code that used to be written is now metaprogrammed. Previous use cases that required C macros largely have native C++ equivalents at this point.
The major issue that makes C++ seem complex is the standard library, which was largely designed and written for legacy versions of C++. If you use the standard library heavily, it tends to want to be used in the style of C++ for which it was originally written. If you built a standard library for C++20 from first principles, it would look quite different from the one we have. Hence the proliferation of non-standard "standard" libraries for C++.
> 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.
I'm not sure your code is simplified either because of the modern features of C++ or because of the rewrite.
That said, I like the idea of rewriting old C++ code with modern C++. That'd be also a good way to learn modern C++ in a practical way and having legacy code serves well for this context ;-)
A language in the niche of C++ is always going to be complex (see rust), although possibly not as complex as C++.
I think that Carbon is not meant to be 100% backward compatible at least at this point, so they can iteratively try to smooth the rough edges of the language.
This seems to be a very hard idea to convey to people. Zig is on the opposite extreme-- the mantra being "There must only be one way to do something". Ergonomics and simplicity seem to be overlooked aspects of programming language design
That's great if there is one developer working on each component of the software. The moment you have people trying to do cross-component changes, or developing someone else's component, they don't just have to learn how the code works on a domain level, but also the features of the language the code is using.
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++.
Well upto certain limits versatility is important. But, being too versatile also brings more complexity and it makes language confusing. I read more code than I write, so this versatily is not good for people like me.
Isn't the 'kitchen sink' approach what ended up causing Perl to fade from relevance? I am only casually aware of this, and I may be totally misremembering things, but Perl used to be seen as a swiss army chainsaw but people eventually came to realize that maintenance was a nightmare.
It's not inheriting the complexity though. That's sort of the whole goal - the next 'generation' of C++ that can be used interchangeably with actual C++ but allowing re-visiting most of the design decisions and throwing out old features.
The Github Page[1] says this: "The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax."
Seven years ago someone at Google estimated that there was 2 Billion lines of code in production to support Google Services [1]. Given this was seven years ago the number is probably much higher now and a large chunk of it is C++. Clearly any replacement language for C++ has to seamlessly (as primary design goal at least) consume and update this gigantic C++ code base. Nobody is rewriting all of that from scratch. That pretty much rules out Rust, Golang and various other languages which provide a thin "extern C function" level compatibility at best. Would be interesting to see how the language progresses.
Exactly, Rust has been around for a while and it hasn't reached parity in terms of LoC with C and C++ in Gecko's codebase, presumably because it's impossible to rewrite individual units unless the API is impossibly narrow. This new language will be more like different JVM langs in terms of interop.
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.
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.
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 can find something in between writing new "legacy code", or throwing away your (for a company like Google) absolutely huge investment.
FWIW projects that build for interoperability have a much higher chance of long term success than those that don't. This is true for everything in software, not just programming languages. For this reason alone you can't easily compare Carbon and Rust. Carbon sounds something a little closer to Vala (C compatibility) than anything like Rust
> if you need a better alternative to C or C++...Rust is pretty much the answer. Is that not accurate?
If the thing(s) that you're looking to "better" about C++ are its atrocious compile times and/or the C++ culture's even more atrocious shared aesthetics, then the answer is "no".
I have only dabbled in Rust but I found the interop situation to be less than ideal. Plenty of C/C++ libraries either don't have Rust wrappers at all or have been long abandoned.
I like the ability of Carbon to seamlessly integrate with existing C/C++ code and libraries.
We have more than 5 C++-alike languages that are crawling around already. In some ways they have portions of mutual compatibility. But in practice this only matters if you decide to embrace the complexity of five different programming languages when building your software. It's already somewhat challenging for projects to manage assembly, C, and C++.
assembly, C, and C++ is one of the most "standard" things to do out there. Unless you are talking about non-standard toolchains of course (everything that isn't clang or gcc based). C++ is mostly a superset of C so all the C++ compilers out there have pure C modes, and assembly integrates really well into C and C++ build systems.
knowing neither of these languages i’d rather it be labeled something more clear as neither one of those screams immutable to me. the immutable variant should use the ‘const’ keyword instead.
I admittedly only have moderate experience in Scala, which uses `var`/`val` -- but I am glad Rust opted for `let`/`let mut` instead of a single word to make the distinction. It feels much easier to distinguish between mutable and immutable values.
I wonder if `var`/`let` is easier because the words aren't as close as `var`/`val`? Or maybe it just gets easier with experience?
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 know of is basically a 100% conversion rate. Nobody at Google will use Carbon, nobody outside of Google will use Carbon.
> Why try to compete with Rust while not really being a better Rust?
The linked article explains this: classes defined in C++ can be used in Carbon and vice-versa. It even suggests you stick to Rust if that's not what you need.
Edit: Oops, I assumed that the "linked article" was the github page[1] for Carbon, which is a lot more useful.
I guess the README really does answer my question: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."
My read on Carbon is that Google is in a spot where they have enormous amounts of C++ code flying around in a very idiosyncratic C++ dialect, and standard C++ is not working that well for them. So they are looking to create a C++-compatible language that better serves the needs of their codebase. We've seen this before with Facebook and PHP.
What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression
Very few people are using it at all, outside of calling OSX/iOS APIs. They're using it to weld platform support into a C++ codebase, same way they'd use ObjC for that (instead of writing entire apps in it).
The number of pure-Swift projects I've seen per tempus is far less than pure-ObjC, which I think is the best measurement to comprehend Swift uptake. Nobody wanted an ObjC replacement, Apple misread the room.
It became a kitchen sink language similarly to C++. For all the hate Java gets, they did tackle language development very well - wait a bit for other, niche languages to be your testing ground of new features, and only add what sticks. Swift literally has all the features you can find in today’s modern languages, and they have some inconsistent interactions with each other. Also, even this litany of features isn’t enough to make SwiftUI implementable only as a Swift library, it uses some specifics not available in the language otherwise.
And also, as most apple dev tools, it is the only modern language whose compiler failed under me (other than being slow as hell) - I have never gotten a type inference timed out error in other languages, even though it has been around for a time :D
As for growing a language, this is a must watch (bear with the presenter for the bit, you will soon understand why he talks strangely in the beginning): https://m.youtube.com/watch?v=_ahvzDzKdB0
Golang and C++ don't serve the same purpose. Google internally sometimes uses both to the same effect but that's because Google internally has a bunch of stuff (including new kernel syscalls) that makes highly concurrent server development in C++ palatable.
So why "compete" with Rust? Because C++ compatibility was never a design goal of Rust, so gradual, painless migration from C++ to Rust is a non-starter. The best you can hope to do is rewrite entire subsystems where the API is narrow enough. This new language is obviously going to allow something more like Kotlin or even Swift where codebases will be mixed and new code will be written in Carbon.
Google is contributing to "gradual migration from C++ to Rust" via autocxx and crubit. This Carbon thing looks more like a side project, and is still quite incomplete in many ways.
I don't really get it either. The article says they want to focus on being a more direct replacement for C++ with easier conversions. I don't see that though - take maybe the most important issue, memory safety. As far as I can tell, they either 1. Take the C++ approach of mostly-manual with lots of inevitable mistakes that result, easy conversion, or 2. Rust approach of strict ownership and borrower checker model, which will almost certainly require substantial reworking, just like if they had used actual Rust, or 3. Golang approach, give up and go GC, in which case they won't touch the performance, low level features, and memory footprint of C++.
So which way is this gonna go? Or do they have some other way to do memory management that nobody's thought of yet? If they had that, it'd be much more impressive than anything else they've said so far.
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.
Rust has complicated interop with C++ and it is incredibly difficult to automate useful transcompilation from C++ to Rust. Various dynamic safety tools also don't work when you've got both Rust and C++ working together. The idea with Carbon appears to be a language with a much easier ramp for existing massive C++ codebases.
> Rust has complicated interop with C++ and it is incredibly difficult to automate useful transcompilation from C++ to Rust.
The problem with Rust is that it does not have this built directly into the language and relies on third party libraries. That doesn't really scale properly and some of the solutions are half-automated and needs lots of fine tuning, flag toggles and other configuration for it to work.
Carbon, Swift and D have a different approach in integrating the interop capability directly into the language which does sound like an easier way to automate this use it for existing C++ libraries. But I guess that this approach is not easy, but it seems with D lang, it paid off.
To be pedantic, it already isn't; a small but very important part of Linux is written in assembly (it used to be more, but most of it was ported to C; what's left is a small core which simply cannot be expressed correctly in C).
Still a maybe, and they certainly won't be rewriting any core part of the linux in Rust.
While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.
Readit News
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++ reference model inside out).
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.
If Carbon has the same bizarre move/copy rules as C++ then the effort is wasted IMO.
Rust has implicit copies too, e.g. if you do:
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).What's important about Copy is that, since you said you want to permit Copy here, it's OK if Rust keeps both identical bit patterns alive after the bits are copied. Just keeping both alive is obviously better for trivial types like u32, but on modern hardware it's also true for somewhat more complicated types like &str (which is a pointer and a count) or SocketAddrV6 (an IPv6 address, a port number, flow label and so on).
Thus, in your example, v is being bit copied (at least notionally) in both cases to become the parameter of this foo function, but because v is Copy, we can nevertheless use v again on the next line, the bits in v are still alive. If v was not Copy (e.g. an owned String) then foo(v) consumes v, it's moved into foo and now it's gone, we can't access v on the next line.
The fact that foo(v) consumes v, is why core::mem::drop() is so trivial: https://doc.rust-lang.org/core/mem/fn.drop.html
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.
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.
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).
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.
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.
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.
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.
Rust lacking some of these makes it a somewhat unfriendly language to write libraries in.
It is also important to separate C++ the language from its standard library.
As C++ the language has modernized, it has dramatically reduced the lines of code to express a given thing. And the more modern way of expressing the thing has stronger type safety, more flexibility, and better composability. Things that used to require a lot of template metaprogramming magic to pull off are now clean one-liners. Particularly in C++20, which is probably the biggest step-change since C++11, metaprogramming is simultaneously much more powerful and much more readable. A lot of code that used to be written is now metaprogrammed. Previous use cases that required C macros largely have native C++ equivalents at this point.
The major issue that makes C++ seem complex is the standard library, which was largely designed and written for legacy versions of C++. If you use the standard library heavily, it tends to want to be used in the style of C++ for which it was originally written. If you built a standard library for C++20 from first principles, it would look quite different from the one we have. Hence the proliferation of non-standard "standard" libraries for C++.
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.
Any examples for this? My knowledge stopped at boost and I guess there are more.
That said, I like the idea of rewriting old C++ code with modern C++. That'd be also a good way to learn modern C++ in a practical way and having legacy code serves well for this context ;-)
I think that Carbon is not meant to be 100% backward compatible at least at this point, so they can iteratively try to smooth the rough edges of the language.
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 Github Page[1] says this: "The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax."
[1] https://github.com/carbon-language/carbon-lang
[1]. https://www.wired.com/2015/09/google-2-billion-lines-codeand...
> 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?
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.
What exactly does this language solve in Google’s problem domain that can’t be enforced through guidelines?
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.
Deleted Comment
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 can find something in between writing new "legacy code", or throwing away your (for a company like Google) absolutely huge investment.
FWIW projects that build for interoperability have a much higher chance of long term success than those that don't. This is true for everything in software, not just programming languages. For this reason alone you can't easily compare Carbon and Rust. Carbon sounds something a little closer to Vala (C compatibility) than anything like Rust
If the thing(s) that you're looking to "better" about C++ are its atrocious compile times and/or the C++ culture's even more atrocious shared aesthetics, then the answer is "no".
I like the ability of Carbon to seamlessly integrate with existing C/C++ code and libraries.
https://github.com/carbon-language/carbon-lang
Helps with quick auto-completion, and someday when I get to dictate code, fewer mistakes.
I wonder if `var`/`let` is easier because the words aren't as close as `var`/`val`? Or maybe it just gets easier with experience?
The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I know of is basically a 100% conversion rate. Nobody at Google will use Carbon, nobody outside of Google will use Carbon.
It's going to be worse than the Swift implosion.
The linked article explains this: classes defined in C++ can be used in Carbon and vice-versa. It even suggests you stick to Rust if that's not what you need.
Edit: Oops, I assumed that the "linked article" was the github page[1] for Carbon, which is a lot more useful.
[1] https://github.com/carbon-language/carbon-lang#why-build-car...
What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression
The number of pure-Swift projects I've seen per tempus is far less than pure-ObjC, which I think is the best measurement to comprehend Swift uptake. Nobody wanted an ObjC replacement, Apple misread the room.
And also, as most apple dev tools, it is the only modern language whose compiler failed under me (other than being slow as hell) - I have never gotten a type inference timed out error in other languages, even though it has been around for a time :D
As for growing a language, this is a must watch (bear with the presenter for the bit, you will soon understand why he talks strangely in the beginning): https://m.youtube.com/watch?v=_ahvzDzKdB0
So why "compete" with Rust? Because C++ compatibility was never a design goal of Rust, so gradual, painless migration from C++ to Rust is a non-starter. The best you can hope to do is rewrite entire subsystems where the API is narrow enough. This new language is obviously going to allow something more like Kotlin or even Swift where codebases will be mixed and new code will be written in Carbon.
So which way is this gonna go? Or do they have some other way to do memory management that nobody's thought of yet? If they had that, it'd be much more impressive than anything else they've said so far.
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.
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.
The problem with Rust is that it does not have this built directly into the language and relies on third party libraries. That doesn't really scale properly and some of the solutions are half-automated and needs lots of fine tuning, flag toggles and other configuration for it to work.
Carbon, Swift and D have a different approach in integrating the interop capability directly into the language which does sound like an easier way to automate this use it for existing C++ libraries. But I guess that this approach is not easy, but it seems with D lang, it paid off.
Deleted Comment
I thought Linux was C only and Linus is actively hostile against cpp for some good reasons.
It won't be for long (Rust) https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linu... .
But I don't expect C++ to be added.
> It won't be for long (Rust)
To be pedantic, it already isn't; a small but very important part of Linux is written in assembly (it used to be more, but most of it was ported to C; what's left is a small core which simply cannot be expressed correctly in C).
While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.
Dead Comment