The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I'm not too confident that Rust-but-with-OO is enough of a selling point.
Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach.
Your perception (and mine) that rust is about to become the new default for "true native" is perfectly consistent with this, a language for the rust generation for when they have to deal with the c++ legacy. A legacy that won't be going away any time soon. I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't", my perception (from a quick glance at the site) is that they are fully aware of the limitations of the niche they have so clearly staked out.
> I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't"
That is in fact explicitly stated on the Carbon introduction:
"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."
> If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.
Regarding C++. IMHO - it’s not getting intrinsically better. More complex. Easy things become a bit less verbose, but the hardest things remain as hard and the compiler is as unhelpful as before.
I agree C++11 and it’s successors are sugaring the language to be a lot nicer but fundamentally nothing has changed.
Rust is fundamentally better in it’s compiler warnings (they are actually helpful), and contains specific solutions to the things that are hard and bite you in C++.
C++ is not going away and it’s my main professional language but Rust does have features that are better.
Fundamentally, it has smart pointers and std::make_unique now, which means I never have to touch a raw pointer in most of my code. They can even be adapted to wrap Win32 objects. That's a huge improvement and I don't mind using C++ for new projects now.
C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.
I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling?
That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing.
I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution.
Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code?
Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.
You can do things the way you do them in C++ in Rust if you want. You could `cargo vendor`, you could fork a repo & depend on a specific commit, etc. It’s up to you have the self-control to do that though and not just shovel random dependencies into your project, that’s all.
Mostly you seem to be complaining that it’s just to add dependencies? (maybe put a ‘sleep’ in your bash prompt or something?) and maybe that the Rust ecosystem doesn’t have as many duplicate libraries as C++? (of course it doesn’t?)
The problem is that cargo gets in the way (as does rustc) if you try and use it in anything other than the simple import this dependency mode. I spent a hell hole of a day or two, trying to pick up a dependency outside cargo because it didn't behave in a way that meshed with the rest of my build environment.
So, yes it handles a couple of the basic cases, but then your out of luck, stuck in a version hell/etc because rustc and cargo are so tightly integrated and the flags needed to emulate some of the behavior with just the compiler are poorly documented and/or version dependent.
It dictates, you conform (which is basically the rust way).
The problem with the typical rants about C++ is that you guys are outdated.
With Conan you can consume over 1,000 packages directly from build systems and with way more control than what Cargo seems to offer. Take a look. I did use it for a while and compared to 15 years ago things are way better now.
The problem isn't that Conan exists, but that other competing solutions are just as popular which results in fragmentation (for instance vcpkg, and cmake can also directly pull in external dependencies now). In the Rust world there's just Cargo.
In the world of build systems, I think most people want a little more consistency and a little less innovation. Sometimes a tool should just do its job and broadly resemble other tools in the space.
Fragmentation is not the problem. The future of C++ is to have metadata exchange, at least the way I see it.
This means that packages can be compiled with any build system, the one that fits you better. In the event that you cannot find a binary that fits you, your package manager can compile on the fly. There are also solutions to keep binary artifacts in Conan. This means that most of the time you can consume pre-made packages in vcpkg/Conan for casual consumption but you can still have binary repositories with fully customized builds for all your permutations of compilers and systems and debug/release. Do not forget this is a hard problem, we are talking to compilation to native, sometimes you need full speed and a custom compilation, not about portable Java bytecode.
But you can still set up and tweak recipes in Conan and upload to your binary repository (what we do at my company).
However, none of these things tie you to a build system, since conan can generate .pc, .cmake, MSBuild, XCode and way more metadata to consume those packages.
You can scale from simple to fully customized. For example before we had a libcxx that we compiled ourselves and pointed all deps and patched packages and could build something with like twenty-some dependencies with that customized libcxx optimized for us. Can you do that with Cargo? Serious question, I did not make extensive use of it.
However for simple uses you can just drop a conanfile.txt and conan install your profile and start to consume your packages. All of this works with CMake, but if I want to use Meson build system or SCons, Make and others I can do it as well. Look at the generators page: https://docs.conan.io/en/latest/reference/generators.html
I do not think fragmentation in build systems is even a real problem anymore because the "not fragmented but simple" philosophy leaves many things out of the box, such as compiling something custom when you really need it.
The system is very flexible. True that the learning curve is harder at first, but much simpler than it used to be in the past.
I can have full projects, not even with Conan, just with simple Meson wraps (Meson wraps are source-only dependencies though) pointing interdependencies to the same version of a library with a very reasonable amount of work: sometimes a single switch in the options, sometimes a small patch that you can keep in your subprojects/ directory or somewhere else.
I can easily generate .cmake and .pc files from Meson itself without trouble, which are two of the most used build systems. But if on top of that you build a Conan recipe then you can have many consumers of your packages for free.
It is nice to have a tool that is more ore less streamlined sometimes, but build systems is a difficult topic and probably there are some that do a few things better than others: cross-compilation, linux tweaks, generating VS solutions for you if your company uses VS, XCode or whatever. It is not bad to have a choice as long as you can interchange.
I would say it is even better than having the one-size-fits-all thing and later when you want to go to the real native stuff then you discover that your tool is too basic and cannot switch.
> C++ has virtually zero tooling and the committee is not interested in ever working on that
This sentence makes no sense at all:
1 - Tooling does not stop to the build systems
2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memtracers, profilers, thread sanitizers, debuggers, disassemblers, static analyzers, packages managers, bindings generators, ABI checkers, crash analyzers, loggers and I am sure I forget still many others.
Most of the tools you mention work below the language level, and thus work automatically for non-C/C++ languages too (or at least LLVM-based languages).
> Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle
You are wrong here. Cargo serves a set of fixed "this-is-how-to-do-it" thing. In C++ you can build anything. I do not mean it is better, but C++ software already exists and that is the solution that it works better for it. :)
> and the committee is not interested in ever working on that
Besides having lsp (language server protocol), Visual C++, CLion and others, I have been successfully using CMake/Meson paired with Conan and I can tell from experience that it is amazing what you can achieve.
Someone will say Cargo or whatever, which is nice and simple. But with these tools you can choose all details and optimizations as well, something that other tools just hide. But you can still keep it simple with a conanfile.txt for your dependencies and the stock add_executable etc. in CMake/Meson and get done with it. If you feel CMake is subpar (bc its syntax and DSL are terrible, I agree with that) then you can use Meson. It works pretty well.
Hahaha you have zero clue. C++ has the best tooling in the world. From static analysers to best in class debuggers to best in class performance profiling tools etc. No other language comes even close.
Java has far more extensive tooling in all the categories that you've mentioned. I don't know if it's "the best tooling in the world", but if I had to make an educated guess, I'd bet on Java - and I don't even like it as a language.
Most of the tools you mention are actually language agnostic (debuggers and profilers). And static analyzers are much more important for C and C++ than other languages.
But it's worth investigating what you can do when you aren't tethered to wild inconsistencies and odd behaviors and workarounds because the community is terrified of breaking backcompat.
I'm still in the C++ world for work, and have kept reasonably up to date with things to C++17, but I'm sitting here looking at C++20 and wondering is it really worth the effort...
Rust 1.0 is 2015. Hence this is sometimes referred to as "2015 edition" in Rust's edition system.
But the sort of people who are here to tell you about how great C++ is will say well, actually Rust existed all the way back to 2006 as Graydon's personal project. There were no numbered releases until Rust 0.1 (after C++ 11) and modern features like Traits don't appear until much later, but sure, in this sense Rust existed in 2006.
I had the same question as you so I checked. C++ 11 standard was released in 2011 of course. Rust development started in 2006 and Mozilla announced it officially in 2010.
It's a bit weird to take the release date for one, and the start of the development for the other. By that measure, the first pre-alpha (!) release of Rust was in 2012; the first stable release in 2015. On the other hand, the first RFC for C++0x was in 2008.
As far as I'm concerned, C++ is there for legacy purposes only.
There are some nice frameworks and tools using it, sure. Yes, you are required to learn it if you are studying CS.
Any serious new development today is done using more modern languages such as Rust (i.e.: the linkerd service mesh proxy [1] for encrypted pod communication in a k8s cluster).
As even the Linux kernel is slowly transitioning to using Rust [2],
it's only a matter of time before an inflection point is reached and it goes mainstream (if not already.)
Hahaha wow. There are more than 5 million C++ programmers out there. Starting new C++ projects every day. I am pretty sure more new C++ projects are started every day than Rust projects. Everything (including Rust) runs on top of browsers/operating systems/drivers/compilers/VMs written in C/C++. Rust code is like a drop in the ocean compared. Maybe in 30 years that will changed? Don’t count on it.
To be fair, parts of my work codebase are touching on 25 years old, and I work for a startup from 2020. The codebases we're building on have roots in the mid 90s, and the platforms they run on didn't support modern C++ standards for a very long time after that.
So anything including "windows.h" isn't really new development then? Sounds like a strange definition.
I'd say that there is a lot of new projects being started with C++, still way more than there are new projects in Rust, at least if you only count serious ones.
I mean a lot of these things rely on copying old code. AFAIK a lot of new games in bigger studios start by essentially copying the old engine into a new tree.
what languages you learn at university highly depends on the specific school you are at, the professors, and which companies are donating the most money. it's certainly not a great representation of what is going on in the industry as a whole.
Yes that is true but I'm responding to the up stream comment saying "you are required to learn it if you are studying CS". There is a common perception that computer science degrees are about learning things like C++ but my experience is that most emphasise more abstract skills like data structures, algorithms, complexity, formal program design, etc.
Not at all. Computer science and engineering (I think this is different degrees in US but in Spain it was a BS + Master when I studied) is about algorithms, data structures, big O notation complexity in algorihtms, client/server architecture, hardware and assembly, understanding all the underlying math, networking, even HPC and advanced data structures when you keep choosing specialized subjects, but not learning a single tool for the sake of it for programming.
In fact, it is the least relevant part when you are studying. You learn tools better after you end the degree IMHO.
It really depends on what bit of computer science you are learning.
C++ is definitely past its prime and has been surpassed in many areas by other languages but there are still a bunch of domains where it is the primary language.
How about almost all domains? Everything in the world runs on top of browsers/operating systems/drivers/VMs/networks/embedded systems etc. that are written in C/C++. Not to mention that the tools used to design chips and manufacture them are also written in C/C++. No other language comes even close.
Having C or C++ somewhere in the lower levels of your stack doesn't make them the primary language for your domain. Other wise CPU microcode would be the primary language of every domain.
In fact there is plenty that can be expressed only in C++. A person making effective use of the power of the language finds anything else a huge step down.
Anyone not having fun when coding C++ is doing it wrong.
In C#, nested classes are effectively friends with their outer class, and it's used quite often in practice.
On the other end of expressivity, in Eiffel, every class member is declared as visible to specific other classes; if you want something to be public, you say that it's visible to ANY, which is the universal base class similar to e.g. Object in Java.
> Rust (from my biased point of view) is currently on its way to become the standard low-level language
The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10, and Rust is already 7. Any language could, of course, be an exception to historical trends, but there's nothing to suggest that is the case.
More anecdotal adoption stories are just as bleak. Even at this relatively advanced age, many companies dabble in Rust — as they did in, say, Haskell — but not many established companies have yet to really bet big on it.
The only positive is that among the low-level languages discussed on aspirational sites, Rust is, indeed, the most talked-about language, but history also suggests that that is a very bad predictor of long-term market success.
> programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10
Notable exceptions from the links you've provided:
C#, Java, Go, PHP. All appear to have an upward trajectory today.
Javascript has also seen a similar penetration boost when nodejs came on the scene.
With rust looking to get integration both into the Linux kernel and GCC, that points to some pretty positive things for the language's penetration. Particular in the embedded world.
They might have an upward trajectory, but they're not posed to break well beyond their respective records. With the possible exception of Python, how popular a language is at age ten is a reasonable rough indicator of how popular it's ever going to be. At its current growth rate Rust would reach 1% market share at age ten. Again, there can certainly be surprises, but I think it's weird to say that actual current evidence clearly points to success for Rust. On the contrary, to become a success it would need to buck the trend and be quite a surprise. So it could happen, but I don't see much to support the claim that this is what's currently happening.
> With rust looking to get integration both into the Linux kernel and GCC, that points to some pretty positive things for the language's penetration.
I agree that it shows that the language is taken seriously and isn't dismissed as a possible option, and that that's very good. That indicates that the language isn't an immediate irredeemable failure, but I don't think it's an indicator of future success.
> That indicates that the language isn't an immediate irredeemable failure, but I don't think it's an indicator of future success.
I'd simply point to the fact that there are very few languages that have tried to get into the same space that rust exists in. Even something like D came with an optional GC which has pulled it out from consideration for things like the kernel or embedded devices.
When you say "most languages are peaked at 10 years" I'd simply point to the fact that rust is substantially different from most languages. It's not tackling the same market spaces. The ones it is hitting have been slow moving for a while now.
Major problem with GC languages is that it is horribly to link against libraries that ships with a GC. Lets say I want to use 10 libraries, if each has their own GC then my program is now running with 10 GC's each trying to optimize itself, which isn't a tenable situation.
So system level libraries has to work without a GC, even though system level programs can work fine with a GC.
For java the virtual machine provides the GC for everything, but then you can only use JVM libraries and not libraries in other languages.
The reason C and C++ libraries can easily be included in basically any other language is that they don't have a GC, so there are no such issues, just call the functions and things works fine.
> Major problem with GC languages is that it is horribly to link against libraries that ships with a GC.
I'm curious which GC languages do this. The most popular ones that come to mind for me are anything on the JVM, JS, and Go, and I've never heard anyone point this out about them.
Libraries work fine in GC languages if they're written in that language. But you can't easily take a library written in Java and import it into your Python project (you can do it, but it's not efficient, and the more languages you include the less efficient it gets). Whereas libraries written in C/C++/Rust/etc can have binding in every language without issue. Consider libraries like zlib or curl and SQLite that are ubiquitous is across every language ecosystem. Those are the libraries that need (well, greatly benefit) from being written in a non-GC language.
Every language with a GC has this problem. If you want a library to be used in both Java and Python you don't write it in either Java nor Python, you write it in C++ or another language without a GC and import that to Java and Python. Trying to import a Java library in Python or vice versa is horrible, since GC's are very hard to work with from outside the language ecosystem.
I don't know about Java, but it's trivial to import a .NET library in Python with a high-level mapping that takes care of everything GC-related automatically:
But this is exactly the point, it is possible, but once you import such library into Python, you are running both Python runtime and .NET runtime, both having their own GC implementations and many other processes.
But every language needs to get a foothold within its hype period. In a few years the hype for Rust will die down, at that point you wont get new blood unless they are forced to learn it so it will be hard to grow.
Programmers are forced to learn C++ since many jobs require it. Students were forced to learn Python since teachers choose it as a language at universities. You need some reason like this for a language to thrive after its hype cycle is over, and currently there are no such reasons forcing programmers to learn Rust and it doesn't look like there will be any within a few years either.
Except I didn't say "most languages are peaked at 10 years"; I said virtually all languages reached or neared the ballpark of their peak at age 10, from the most to the least successful ones, and those include C, C++, and D. I think Python might be the only counterexample. So it's always possible that some other language would be another exception, but there's nothing today to indicate that Rust is gearing to be such an exception or that it is substantially different from all the languages in all domains that have exhibited that behaviour.
I do agree that it's more likely that Rust is an exception than, say, Scala or perhaps even Go, but the same would be true for, say, Carbon. I.e. while the likelihood is higher, there's nothing at the moment that would indicate that's what's happening.
Obviously Rust has garnered more enthusiasm among PL fans than D ever did, and its peak would probably be higher, but technical enthusiasm and hype is very weakly correlated with long-term success in the world of programming languages. Most charitably you could say it's a necessary condition, but it is very clearly not a sufficient one.
Rust very much could still fizzle. If it does, it will be because it failed to change to be adoptable by more users. All existing users are tolerant of niche qualities. If it succeeds, the programmers who already know it will constitute less than 2% of the total, and the 98% will have picked it up after it changed to be more readily taken up.
If it fizzles, current users will always be at least 70% of the total.
So, if you want it to succeed, you will need to welcome the changes that can get it there.
I think all new languages have some challenges that would make it very hard for them to become as popular as older languages (none of the top five languages is under twenty years old).
For one, we're long since in an era of diminishing returns — new languages have a smaller ROI compared to incumbents than the incumbents had to the languages they replaced — while the cost of a switch is the same if not higher (because codebases are larger). So switching to a new language is just not as profitable today as it was twenty years ago.
For another, the market is more fragmented today than it was, say, 15 years ago. For example, while Java is not the only game in town on the server as it was in, say, 2003-2006, no other single language shows any signs of becoming as dominant as that either. Some use Python for server-side applications, some use JS, some use C#, some use Kotlin, and some use Go. There is no single language that people flock to and so Java is still the dominant server-side language (although for a while PHP seemed like it could be it). So even if Rust does gain actual traction, it's very unlikely to become the standard low-level language. Some may use Rust, some may use Zig, some will use C++, some will use C, and maybe some may use Carbon. The only new language around that seems capable of reaching a popularity similar to ~25 year-old languages is TypeScript.
I also think Rust has a fundamental problem specific to it, and that is that it's a complex, rich, language. Rich/complex languages have never been super-popular, and while C++ is arguably more-or-less as complex as Rust, it wasn't when it gained its market share (only to lose much of it shortly after).
Language complexity is a poor measure. Better is the complexity of using a language to achieve an aim. C and Pascal are pretty simple as languages, but they make it substantially more complex to complete a task, because they lack the expressive power needed to help any.
C++11 is substantially more complex than C++98, but much simpler to program with. Rust is both simpler than C++ (at surface level, because it leaves behind cruft C++ cannot) but more complex because it makes greater cognitive demands (to satisfy the borrow checker) and also because it lacks powerful features C++ offers. C++ is better able than Rust to package semantics in a library and deliver that to users on command. But Rust is way, way better in that way than C.
GP said the standard low-level language. Low-level code will always be a much smaller percentage of all code than the heaps of web apps our industry is shitting out on a daily basis.
Thus it would be completely reasonable for the de facto sysdev language to have a small market share overall(unless like for C/C++ there is a lot of legacy stuff to maintain) . Your sources don't shine any light on this at all.
Different metrics tell a different story. For example GitHub pull requests [1] are C++: 2.60%, Rust: 2.09%, C: 1.43%, with a clear trend showing Rust ahead of C++ next year. Or you could look at the Stackoverflow survey of languages used among professionals [2], which gives C++: 20.17%, C: 16.7%, Rust: 8.8%, with rust gaining 1-2% each year.
There's no best metric, they're all biased, you need to consider a few different ones. Otherwise you won't notice when you've stumbled upon one with with an extreme view.
Combining C and C++ in language stats is debatable, they should IMHO be measured separately. When grouped as a language category, "C/C++/Rust" is slowly becoming more common.
I assume 1 is pulling only from github.com public projects. Many companies A: don't make their code public, B: probably use github enterprise/other hosted solutions (esp including not git based)
Yes, public github repos, stackoverflow survey respondents, devjobscanner offers, google searches, etc are all skewed in some way.
It's very hard to qualify the effect of those biases though: for example how does the public/private repo ratio differ between languages ? Good luck giving a trustworthy answer to that. Apart from looking at lots of different source kinds, one thing that's fairly trustworthy is the trend of a specific language in a specific source.
On that topic, looking at the "SO questions" metric of the first link, C and C++ both have a strange regular spike in the last quarter of each year. I attribute that to new CS students flocking to SO at the beginning of their term. Another fun trend to look at is the hourly google searches over a week: the weekdays / workhours spike is much more pronounced for some languages than others.
I think looking only at the number of dev jobs leaves too many potential confounding factors to be useful. For instance, how many C/C++ jobs are actually companies who need those devs to move away from C/C++? What's the overlap? How much of the C/C++ share is maintaining legacy code vs starting new projects? Sure the data says something about it, can we draw any conclusions from it other than precisely the numbers you listed? Not really, not without more detailed data.
One thing I would welcome is specifically looking at new sysdev projects over time and what languages they're in.
To be clear I'm not taking a view on whether Rust will become the standard. I really don't know, and I've yet to see anything convincing me one way or the other.
Sure, but even low-level languages have tended to reach the ballpark of their all-time peak market penetration -- however high or low it is -- around age 10.
"... around age 10." C++ (not to mention C)? IIRC, I remember seeing B.S.'s "C with Classes" appear in ACM SIGPLAN Notices in the early 1980s -- 40 years ago. I don't think it hit its peak 10 or even 15 years after its early development. Given that it's C++, that's a pretty major exception.
C++ was huge in the 1990s, C++'s share is probably smaller today than back then since so much of programming has moved over to managed and scripting languages.
>programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10
How are you coming to this conclusion? I can think of more counter examples than actual examples (Almost every language on the top 10 aside from PHP where close to peak market penetration at age 10).
Key players like Microsoft and the Linux Kernel developers are only just beginning to pick up Rust. It's been considered promising, but immature for much of it's lifetime, and it's only recently gotten to the point that it's considered mature enough for core infrastructure projects (which are really it's forte) in the last couple of years.
I don't think rust is headed to be the norm, but I don't think it should be compared to most mainstream languages. It's not python/php/ruby.. it's a very difficult niche where a lot of efforts failed flat.
> The syntax looks a lot like Rust, though. I'm surprised they made such a break
Convergent evolution. Rusty syntax is pretty close to what you get if you want to make a language look broadly similar to C/C++ while avoiding pathological and/or computationally difficult parsing.
> on its way to become the standard low-level language
It will take a very long time for Rust to get even close to the huge amount of C++ code out there. There are more than 5 million professional C++ developers employed around the world today. And that number is increasing. Don’t get me wrong: I like Rust and other attempts to move beyond C++. But don’t underestimate how much C++ code has been written the last 30+ years. And new C++ projects are started every single day. There are probably more C++ projects started every day than Rust projects. So anything that makes it possible to move beyond C++ while being 100% interoperable is good news.
Carbon is not trying to be 100% interoperable with C++. It's trying for some fuzzy notion of "good enough" - that's really not very different from what Rust is trying to do with cxx-rs. Yes there are serious challenges and I've described them here, but they're not impossible to address while staying with Rust.
Oh, that's excellent and interesting news - not a fan of exceptions. I'm not sure how that's going to work with interop when libraries rely on exceptions though. Where did you hear about this? I'd love to know more.
Rust is like c++ but only the new way to doing c++ is huge rust is like subset of c++ and ownership model.
I thing is the right way c++ is harder than rust only because is so bloated.
Carbon seams less bloated "fork" of c++ whit only the new way of doing things, but allow you full interoperability whit all c++, instead of partial and i don't see ownership, i thing is taxing mentally (worth or not depends).
if i work in c++ i totally will use this.
I don't know about it becoming the standard LL language yet. There's a lot of memory management in low level programming, and peppering everything with unsafe seems like it'd be tedious. I'd rather just write in C to begin with.
I'm interested in seeing how things are handled with the Linux kernel's rust support, if it ever becomes more than a proof of concept. That will be a good viability test.
