Can Google's New Programming Language 'Carbon' Replace C++ Better Than Rust? (thenewstack.io) 185
It's difficult for large projects to convert existing C++ codebases into Rust, argue Google engineers — so they've created a new "experimental" open source programming language called Carbon.
Google Principal Software Engineer Chandler Carruth introduced Carbon this week at the "CPP North" C++ conference in Toronto. TechRadar reports: The newly announced Carbon should be interoperable with the popular C++ code, however for users looking to make the full switch, the migration should be fairly easy. For those unsure about a full changeover, Carruth delved into more detail about some of the reasons why Carbon should be considered a powerful successor to the C++ language, including simpler grammar and smoother API imports.
Google's engineers are already building tools to translate C++ into this new language. "While Carbon began as a Google internal project, the development team ultimately wants to reduce contributions from Google, or any other single company, to less than 50% by the end of the year," reports The New Stack, adding that Google ultimately wants to hand off the project to an independent software foundation where development will be led by volunteers: Long the language of choice for building performance-critical applications, C++ is plagued with a number of issues that hamper modern developers, Carruth explained on a GitHub page. It has accumulated decades of technical debt, bringing with it many of the outdated practices that were part of the language's predecessor, C. The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux and its package management ecosystem, Carruth charged.
The language's evolution is also stymied by a bureaucratic committee process, oriented around standardization rather than design. Which can make it difficult to add new features. C++ has largely a sequestered development process, in which a select committee makes the important decisions, in a waterfall process that can take years. "The committee structure is designed to ensure representation of nations and companies, rather than building an inclusive and welcoming team and community of experts and people actively contributing to the language," Carruth wrote. "Access to the committee and standard is restricted and expensive, attendance is necessary to have a voice, and decisions are made by live votes of those present."
Carruth wants to build Carbon by a more open community-led environment. The project will be maintained on GitHub, and discussed on Discord.... The design team wants to release a core working version ("0.1") by the end of the year.
Carbon will boast modern features like generics and memory safety (including dynamic bounds checks), the article points out. And "The development team will also set out to create a built-in package manager, something that C++ sorely lacks."
Google Principal Software Engineer Chandler Carruth introduced Carbon this week at the "CPP North" C++ conference in Toronto. TechRadar reports: The newly announced Carbon should be interoperable with the popular C++ code, however for users looking to make the full switch, the migration should be fairly easy. For those unsure about a full changeover, Carruth delved into more detail about some of the reasons why Carbon should be considered a powerful successor to the C++ language, including simpler grammar and smoother API imports.
Google's engineers are already building tools to translate C++ into this new language. "While Carbon began as a Google internal project, the development team ultimately wants to reduce contributions from Google, or any other single company, to less than 50% by the end of the year," reports The New Stack, adding that Google ultimately wants to hand off the project to an independent software foundation where development will be led by volunteers: Long the language of choice for building performance-critical applications, C++ is plagued with a number of issues that hamper modern developers, Carruth explained on a GitHub page. It has accumulated decades of technical debt, bringing with it many of the outdated practices that were part of the language's predecessor, C. The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux and its package management ecosystem, Carruth charged.
The language's evolution is also stymied by a bureaucratic committee process, oriented around standardization rather than design. Which can make it difficult to add new features. C++ has largely a sequestered development process, in which a select committee makes the important decisions, in a waterfall process that can take years. "The committee structure is designed to ensure representation of nations and companies, rather than building an inclusive and welcoming team and community of experts and people actively contributing to the language," Carruth wrote. "Access to the committee and standard is restricted and expensive, attendance is necessary to have a voice, and decisions are made by live votes of those present."
Carruth wants to build Carbon by a more open community-led environment. The project will be maintained on GitHub, and discussed on Discord.... The design team wants to release a core working version ("0.1") by the end of the year.
Carbon will boast modern features like generics and memory safety (including dynamic bounds checks), the article points out. And "The development team will also set out to create a built-in package manager, something that C++ sorely lacks."
Prediction: (Score:5, Funny)
The tools Google is building "to translate C++ into this new language" will be called Bubbles.
Because the code will be Carbonated.
Cute, right?
Re:Prediction: (Score:5, Informative)
the development team ultimately wants to reduce contributions from Google, or any other single company, to less than 50% by the end of the year," . . . Google ultimately wants to hand off the project to an independent software foundation where development will be led by volunteers
Google doesn't even give half a fuck about this. It's just something that some bored engineers are throwing out there so they have something to talk about at their next performance review.
Why? (Score:2, Insightful)
Re: Why? (Score:3)
Because of stupid people that can't handle the power of a real language
Re: (Score:2)
Re: (Score:2)
The tools Google is building "to translate C++ into this new language" will be called Bubbles.
Because the code will be Carbonated.
Cute, right?
Carbonated? Drunk is more like it [imgur.com].
So it is Swift then (Score:2)
Re: So it is Swift then (Score:3)
No it can't be. Swift is lipstick on an objective-c that pretends to be cross platform so that apple can try to convince k-12 institutions to teach it so they can get more app store revenue. But it sounds like this one is intended to actually be cross platform.
Re: So it is Swift then (Score:2)
Theres no reason for Apple not to embrace modern C++ now for its APIs other NIH syndrome. They're missing out on a lot of talent developing for their platform by being so stubborn about it.
Re: (Score:2)
Theres no reason for Apple not to embrace modern C++ now for its APIs other NIH syndrome.
Uhm, it's Apple you're talking about. They don't need an external reason. NIH is their modus operandi.
Re: So it is Swift then (Score:4, Interesting)
All Apple APIs are C++ APIs, since 20 years or something, probably longer. my first C++ projects where on Macs around 1989/1990. At that time they started to replace - or gave an alternative to Pascal as API.
Since Mac OS basically everything is C++, with convenience layers/wrappers in Objective-C and now Switft. You can program a Mac in plain vanilla (if that makes sense in C++ terms) in C++ only, never seeing any "helper library", any Swift, or any Objective-C. That is/was basically always the case. (Same for iOS,iPad OS)
No idea what your completely bollocks rant is about.
Re: (Score:3)
> Swift is lipstick on an objective-c
That's far from being a fair description of Swift, IMHO.
While it is being compatible with Objective-C's object model, it is a great deal different.
For one thing, it does not inherit C's notion of undefined/implementation-defined behaviour. It adds recoverable exceptions and structured concurrency.
But yes, I'd think that its link to Apple is a problem for getting it widely accepted on other platforms.
Re: (Score:2)
Swift also sounded like it's intended to be cross platform...
Re: (Score:2)
Except that Swift and Objective-C have nothing to do with each other except utilizing { and } - (* facepalm *)
Re: (Score:2)
It's compiled Java.
Comment removed (Score:5, Insightful)
Re:Maybe but... (Score:5, Funny)
Re: Maybe but... (Score:2)
I don't see people going out buying a different hammer every time they whack their thumb with it
Re:Maybe but... (Score:5, Insightful)
Bjarne Stroustrup, "The C++ Programming Language"
Rust is not better than C/C++. Its current popularity is mostly hype. It has some specific benefits over C/C++ but those come with some distinct costs. If its adoption really does get anywhere near the level of C/C++ adoption, those problems will become prominent enough that everyone will be complaining about those just-as-much-or-more as people complain about woes in C/C++.
Another language is just another different set of trade-offs, not a fundamental solution to the problems of prior languages. It doesn't matter how many more of these we create, this will remain true of all of them.
Re: (Score:2)
Rust if vying for the same domain as C++ and it is not 10x better than C++; overall it is probably not better at all, just different.
A language that stays is either 10x better than the top language in the existing domain or is 10x better than any other language in a new domain (go comes to mind). Same, in a way, as with any other market -- it needs to find its "product-market fit" to be successful.
Re: Maybe but... (Score:2)
Is c++ 10x better than c? Given the name, I think it only intends to be one better than c. Yet it seems to see a lot more usage. But if you think rust is going nowhere, then you aren't looking very hard.
Re: (Score:2)
C++ is exactly one increment of the orders of magnitude better than C, for a certain large class of applications (not the Linux kernel).
A language is a tool, a tool has its market share, a new tool overtakes the old tool in that same market if it is 10x better and entices more people to switch, or it conquers a new market and entices more people interested in that market to start using it. Maybe rust is an exception to the rule but at the moment I don't see any reasons for it.
Re: (Score:3)
Care to elaborate?
Re: (Score:2)
The main advantage (is this really an advantage?) is that Carbon is completely interoperable with C++ code, so you can call into Carbon code from C++, and C++ code from carbon. This might not be an advantage because now a person has to learn two languages to use your codebase.
The primary motivation seems to be that C++ types have gotten so convoluted (starting with Boost and only continuing from there) that the code is hard to read or write. The situation is not improved when you have coworkers who are not
Re: (Score:2)
The main advantage (is this really an advantage?) is that Carbon is completely interoperable with C++ code, so you can call into Carbon code from C++, and C++ code from carbon.
Doesn't this "advantage" also describe C?
Re: (Score:2)
Google has put a lot of effort into rewriting their C code as C++ code in Android.
Re: Maybe but... (Score:2)
Re: (Score:2)
Re: (Score:2)
I'm not familiar with D's interoperability, so I can't answer that.
What I see from Carbon so far is that it's just like a fancy Macro language on top of C++ (some people will argue with my use of "macro" here, but there's a clear relationship between each line of Carbon code and each line of C++ code that can be easily converted with a smart pre-processor).
D diverged from C++ longer ago, so I would have questions about how complex types interact with D code, and how smart pointers in C++ interact with D cod
Re: (Score:2)
A safe subset is planned to be created somewhere down the line.
Betteridge's law (Score:2)
But a whole lot of new jobs will be created soon, specializing on it.
Re: (Score:3)
But a whole lot of new jobs will be created soon, specializing on it.
Jobs requiring a minimum of 5-years' experience.
Re: (Score:2)
Soon?? Recruiters are already looking for people with 10+ years experience with Carbon...
Re: (Score:2)
But a whole lot of new jobs will be created soon, specializing on it.
If that's true, I bet those job postings will require a minimum of 5 years experience with the language...
It worse than that: The article is dead Jim, dead. (Score:3, Insightful)
The bar for a "better than rust" C++-replacement-wannabe is low. Besides, the rust kids seem incapable of coming up with projects of their own. Their adoption efforts are always centered around pissing in someone else's stew. Rust-coloured piss, go see your doctor.
C++ is a large and complex language so the bar for a "C++ replacement" is quite high. rust certainly can't do it.
The result is that this is obvious clickbait. And probably more than a little hubris.
As far as this new language is concerned, if i
Re: (Score:2)
The bar for a "better than rust" C++-replacement-wannabe is low. Besides, the rust kids seem incapable of coming up with projects of their own. Their adoption efforts are always centered around pissing in someone else's stew. Rust-coloured piss, go see your doctor. C++ is a large and complex language so the bar for a "C++ replacement" is quite high. rust certainly can't do it.
My impression is that Rust was never meant to replace C++; at best it was meant to replace C. Some people hype up Rust like it is meant to replace everything.
Re: (Score:2)
Now google already came up with a "better" programming language. Nobody cares to ask, why this "carbon" since they already have "go"?
Go replaced C++ on the server, and it does a good job of that.
Carbon aims to replace C++ in Android. One might ask, "Why not just use C?" But why be simple when you can be complex?
Re: (Score:2)
C++ or (no idea about it) Carbon are only more complex in the sense of grammar, and what you can do with it.
C on the other hand is much much much more complex in the ways hoe you can shoot yourself into the foot/feet.
And then again: why would anyone who is not a masochist write 30 lines of C that can be expressed in 3 lines of C++?
I guess different people have a different idea what "complex" means or implies.
Re: (Score:2)
OTOH, being able to seamlessly interoperate with existing C++ code is a real bonus. A language that was faster to code in, and could do that, would immediately catch my interest. But I'm not at all sure that Carbon will meet the "faster to code in" requirement.
Re: (Score:2)
It's a little early to ask, don'tcha think? (Score:2, Insightful)
I mean, come on... it's apparently not even a language yet - it's mostly just a plan put together by one or two individuals.
"Carbon will boast modern features like generics and memory safety" (emphasis mine)
I realize this story exists here for PR purposes, so carry on. But my own prediction is this gains zero traction and is pretty much dead by this time next year.
Re: (Score:2)
C++ has generics.
C++ can also have memory safety if you just use std::string/std::vector/etc. instead of pretending you're doing C++ when you're really just doing C with a C++ compiler.
eg. This can throw an exception on every true-Scotsman C++:
std::vector<int>myArray = { 1,2,3,4 };
int a = myArray[4];
Re: (Score:2)
"Memory safety" my ass:
(I can already hear the retort: "Don't do that! That's stupid. That only happens to people who hire idiots!" Maybe, but consider the possibility that inserting the friend instead happens 5 function calls down in a different source file written by a differen
Re: (Score:2)
I imagine there is a cat and mouse game between the lameness filter devs and the swastika dude
Re: (Score:2)
(I can already hear the retort: "Don't do that! That's stupid. That only happens to people who hire idiots!"
The retort would be that "party" should be a std::set<attendee> to avoid duplication therefore that code is wrong.
*Note, replace "/" with angle brackets. The lameness filter thinks a single less than sign looks like "ASCII art", but for some reason it can't detect giant ASCII swastikas.
Try typing "<", etc., it's HTML 101.
Re: (Score:2)
No, the container was a list, for whatever reason. I didn't say there couldn't be duplicates.
The reason that you'll get a segfault (you *did* know that's actually why the code is wrong, didn't you?) is because the iterator was invalidated by inserting while in the loop. To avoid these kinds of unsafe memory bugs in C++, you have to have an encyclopedic knowledge of the matrix of every container type, iterator type and iterator operation, along with which of these combinations invalidate iterators and which
Re: (Score:2)
You're right. And, if you're smart enough to be able to do that, you will produce the highest-performing code anywhere.
And if you're not, or you lack the discipline, then you won't. And so, you should use a less-performant language. There will still be traps in that language, and you will still write code that either crashes, or locks up, or whatever. But for some reason, you might feel happier about it.
Re: (Score:2)
That's memory safe if you're using single threaded execution. If you're using multiple threads things get a lot more complicated.
But my real complaint against C++ is that it's so verbose. Things that should be a single line frequently take up 5 or 6 lines. This makes things difficult to follow.
Even the "std::vectormyArray =" is pretty verbose compared to, O:
int[4] myArray = for a fixed length array, vs.
int[:] myArray = for a variable length array.
That would let you keep:
int myArray[4]; for the C equiv
Re: (Score:2)
Code verbosity never bothered me THAT MUCH especially if I am giving an explicit description of what I WANT the program to do.
Without some code verbosity I think you are placing TOO MUCH TRUST in the compiler behaving the way you expect it to behave rather than the way it decides to behave.
Trusting a computer to do the right thing is usually not a good idea. Compilers have been teaching that lesson for many decades now.
Re: (Score:2)
Everything that I mentioned was just as explicit as the more verbose C++ version. The verbosity doesn't add ANYTHING of value. And makes it more difficult to follow the flow of control.
Re: (Score:3)
But my real complaint against C++ is that it's so verbose. Things that should be a single line frequently take up 5 or 6 lines. This makes things difficult to follow.
Even the "std::vectormyArray =" is pretty verbose compared to, O:
The goal should be code readability, not terseness.
On a large program you'd use more "typedef" and "auto".
typedef vector<int>int_array;
int_array myArray(4);
It looks verbose in microexamples like this but in real life it makes everything a lot easier to read/modify.
Re: (Score:2)
C++ does NOT HAVE generics.
C++ has templates
And templates in C++ are a HUGE difference versus original generics in Java, and the bastardized version in C#.
No idea what your code example is about. You declare an array with highest index 3, and access a non existing element at index 4. Obviously it throws an exception: just like expected.
Re: (Score:2)
No idea what your code example is about. You declare an array with highest index 3, and access a non existing element at index 4. Obviously it throws an exception: just like expected.
The point is that many people don't expect an exception in C++. They think it's just like C.
Re: (Score:2)
It does not throw an exception, it crashes.
If one were to try to access the array element using the "at" function, then it would throw an exception.
Why does nobody here appear to understand the language they're either bashing or supporting? Personally, I try to never use any language other than C++ for anything, because I'm old fashioned and believe that performance (in modern terms, this means energy efficiency) is vitally important. I'm also well-versed enough in the language to not get tripped up by it..
Re: (Score:3)
It's Google. So even if it's not. It'll be canceled soon after.
You're really shooting fish in a barrel here! :)
Re: (Score:2)
Is it me or does most of what comes from Google lately seem to be just PR stunts? Quantum Supremacy, Sentient AI, now this...
Another Principal Engineer vying for job security (Score:2)
The use-case is mediocre (re-write AND re-compile decades of C++ code into a hybrid Rust-C++ language).
The arguments against C++ (committee and bureaucracy) ARE THE SAME arguments for Carbon (except the committee and bureaucracy originates from Googl
Re: (Score:2)
The arguments against C++ (committee and bureaucracy)...
I dunno. New C++ releases are coming thick and fast lately.
(Every couple of years or so)
Re: (Score:2)
And a couple years later you get a compiler version that has those new features, then a couple of years later after that there’s a chance that your customer might have a libstdc++.so.6 that has those features so you don’t have to ship your own along with wrapper scripts to set LD_LIBRARY_PATH every time you run something.
I despise codebases that assume you have 100% the latest and greatest. That’s not reality.
My compiler lets me use static-linked libraries.
Standardization? The horror! (Score:2)
It's just an idea at this point (Score:3)
Far too early to tell. Maybe? The focus on interop like being able to directly consume headers and vice versa make it pretty appealing as a successor language. They've got an awful long way to go before we can start playing with it in anger.
Style-wise, I kind of wish they had stuck a little closer to traditional C-style syntax (with appropriate cleanup), kind of like C# did, but apparently that's no longer hip and modern enough. I'm also not really thrilled it's yet another corporate-driven language, but realistically, those seem to be the only ones that can gain enough traction to stick. I know the governance model is not supposed to give Google a majority stake, but practically speaking, it seems like yet another Google language. I'm willing to be proven wrong here, so will give them the benefit of doubt as I see how things go.
Honestly, one of the best parts of C++ is that, by design, a single corporate entity can't arbitrary change it however they like, and they place an incredible strong emphasis on backwards compatibility. Yes, that also creates a lot of drag and technical debt, but there's value in your 25 year old code being compiled by the most modern C++ compilers without any changes, and which can still interop with the most modern C++ code. Chandler's talk seemed to advocate more of a "move fast and break things" approach, which I suppose is more appropriate for short-term startup development, but which I suspect does have some disadvantages as well, long-term.
I'll take a look at how it evolves over the next few years as it works towards a viable product and maturity. It's certainly got potential, but we'll see if Google can stick it out long enough to push it through to a valid 1.0 release and beyond.
Re: (Score:2)
Yes. Being able to promise to interoperate smoothly with C++ is a lot easier to promise than to do. A whole lot easier.
But if they DO do it, and if the language has a decent license, then it could be interesting. (But don't hold your breath.)
Google. So experienced developers will keep away (Score:2)
1. It's the next big thing ...
2.
3. Cancelled !
No experienced developers waste their braincells and time on Google projects any more.
I'm not particularly excited or upset about it... (Score:5, Funny)
Guess you could say I'm carbon neutral
No. Java and C# tried (Score:5, Insightful)
...and Java did quite well, but C++ is still keeps on trucking. It might be gnarly, it might have cruft but it creates fast efficient binaries which can program to the metal if required. Plus no one is going to bother learning yet another google language given how they treat their brainfarts after a few years. I guess Go is now Gone?
Re: (Score:2)
Go replaces C++ for server code. They want Carbon to replace C++ in Android.
Re: No. Java and C# tried (Score:2)
Go hasnt replaced anything anywhere other than inside Google and with a few fanboy outfits.
Re: (Score:2)
Kubernetes is written in Go.
Re: No. Java and C# tried (Score:3)
Devops - the job title given to sys admins who can knock together some badly written code to do minor tasks and when you say server I imagine you mean some web server plugins, not a from the ground up sockets based multi thread/process TCP/UDP server of which I have written more than I can count in C and C++. Also FYI , gitlab is written in Ruby. Using Go could only be an improvement on that abortion.
Re: (Score:2)
Ruby's a quite decent language, but a bit slow for that kind of operation.
As for go...I've tried their system, and I prefer makefiles.
Re: (Score:2)
Gitlab uses RoR for its web application framework, however, from the doc: GitLab has several daemons written in Go. To install GitLab we need a Go compiler. https://docs.gitlab.com/ee/ins... [gitlab.com]
Why spend so much time describing the committee? (Score:3)
Companies cannot own languages (Score:2)
Re: (Score:2)
Re: (Score:2)
C came from B, but that is obvious or not?
Then came C++ and then some bright compiler crafter (Walter Smart) invented D.
Hm, bogus points if one finds the error above.
Re: (Score:2)
Sorry, but companies CAN own languages. Whether you should invest in a language owned by another company is, of course, a different question. If they own it, but release everything under GPL, or even AGPL, then it would be quite reasonable. But they'd still own it, and you'd be dependent on them for what changes would be forthcoming. (Apple and Microsoft have proven this more than once, though with a different license. But that hardly matters. Oracle proved that their releasing it under GPL isn't quit
If we wanted to replace C++, we would have used D (Score:5, Insightful)
A replacement language for C++ has been around for more than a decade. It even has a bunch of different compilers, can link against and easily use C++ classes and C APIs, etc. The D language [dlang.org] never got widely adopted, however.
The simple truth is that C++ developers are not looking for a replacement and are quite happy with C++. Especially last few years as C++ is slowly but surely evolving in a mostly positive way. Slowly and surely is precisely what C++ developers want.
Carbon is yet another Google language. Yagl. We should make yet another google language compiler compiler. We could call it yaglcc. Or perhaps we should first start a yet another google language inventor compiler?
I think I will yield here because somebody with better recursive acronym skills than me is probably lurking in the dark with some good ideas?
Re: (Score:3)
perpetual instability (Score:3)
So these dweebs want to convert working "but it doesn't have whatever feature I think is cool" code into a morass of instability.
Want to use library X? Yes, but its developer(s) use version n+1 compared to all our existing code, so we have to run a full regression test suite, and by the way, version n+1 breaks 5% of our existing code.
Don't we have enough of that in existing fad languages? Where's the language specification for Rust (no, the source code doesn't provide a generally useful spec)? Yes, there is a guidebook, but with relatively rapid release cycles there is no promise that what is coded today will compile next week, much less next year.
C++ is not my favorite language, mostly because the number of programmers I've met who really understand class derivation, or what it really costs to wrap every byte of memory in a class, is barely more than the number of thumbs on my left foot. There is, however, a really good chance that code I wrote years ago will still compile and run correctly if/when there's a compelling need to move to a newer version of C++.
Re: (Score:2)
or what it really costs to wrap every byte of memory in a class
Depending what you are doing: it costs nothing at all. That is one of the core design principles of the language from beginning on.
And in case you use more advanced features, then a typical object has one single pointer to the vtab (virtual function table of the class) - which is one single array shared by all objects, holding a pointer to each virtual function once.
In case of multiple inheritance an object might have multiple pointers pointing
Google wants unpaid volunteers to support C++ repl (Score:2)
This is news?
I've used the new'ish' C++ standard, and it has memory and concurrent process support in the standard library, and no one is required to use "old", "compatible" features on a new project -- that's a matter of project controls.
But the part I find funny, is Google thinks it can put a C++ replacement on MS's GitHub, and have volunteers support it. Uh...Yeah, right.
This isn't the first time I've seen companies try to throw their work (isn't Google in a hiring freeze?) onto an "open-ish" SCCS" to t
Market testing (Score:2)
My guess is that Google's PR department is testing the waters to see how this new language might be received, and decide if it's worth putting money into.
New hiring requirement on the big laundry list (Score:2)
"Mush have 5+ years experience in Carbon" - 2022
But wait (Score:3)
https://en.wikipedia.org/wiki/Carbon_(API)/ [wikipedia.org]
Copywrited? Trademarked? Notify the lawyers!
Raises hand ... (Score:2)
Carbon should be interoperable with the popular C++ code, ...
If Carbon is to C++ as C++ is to C, shouldn't Carbon really be named C++++ ? :-)
Re: (Score:2)
Re: (Score:2)
Well, you could make it symmetric and call it ++C++ /me hides
Without borrow checker: No! (Score:2)
They're right about package management (Score:2)
I suppose they are correct in the complaints about C++ and package management. In some of the other big languges, package management is more a function of the environments. Sure, Java and C# are a little easier, but you still rely on Maven or nuget which are not part of the language. Microsoft has managed to integrate nuget in their C++ tools as well as vcpkg. I have no idea if Swift, Go, Rust, etc.... have it as part of the language. I think C++ has some upcoming releases with some sort of package manageme
All languages have tradeoffs (Score:3)
All programming languages should accomplish one goal: Translate the intention of the programmer for the computer to execute it. That's what every language must accomplish. If it doesn't, it's pretty much useless.
There's a good reason why there is more than one language. They all have different advantages and disadvantages. Assembler would certainly be the language of choice for its speed and size, but portability sucks, not to mention development speed, and modern compiler can actually create better machine code than nearly all programmers (depending on the compiler, I've seen some that are barely capable of creating bug-free compiles...).
So Java it is? It's very portable and given that there is a library for almost everything, even mediocre programmers can create code fast. Yeah... but the code is bloated and not exactly fast.
And so on.
For Carbon (or Rust, or whatever) to actually replace C, it would have to be better in all aspects. It very obviously doesn't do everything like C because, well, else it pretty much IS C, so what's the point? There has to be a few differences and what now matters is what these differences are. Like said above, every language will have to make tradeoffs in certain regards. Some of the drawbacks the language has may not apply to you, and so the language is better for your application. Some of the advantages the language has may not matter to you, so learning and using the language offers no advantages for your project.
I'm kinda wary with "language killers". We've had many, many of them and most of them vanished into obscurity. Old code also dies hard. Ask anyone whose job security is perfectly outlined by a single word:
Cobol
So they've finally realized existing code matters. (Score:2)
Took long enough.
Huh? (Score:2)
It's all been downhill . . . (Score:4, Insightful)
Re: (Score:3)
Lisp was indeed amazing.
The consequences to me. (Score:2)
Oh, great. I'm in the job market right now with a resume with a reasonable number of languages cited in it. This means I am now going to have to deal with recruiters with "hot" job requisitions requiring "at least 5 years" of demonstrated experience with Carbon.
The language itself? (Score:2)
All this information about a language's "steering committee" and "community leaders", but nothing about the language itself.
I would love to see a description of the language itself, so I can see for myself whether it would be a good replacement for C++. Without such information, this article is actually useless.
Re: (Score:3, Insightful)
Those who don't understand C++ are doomed to reinvent it.
Badly (Score:2)
Hello Java!
Re: (Score:2)
I believe you mean C#. It started out as Java and is becoming C++.
Re: (Score:2)
C++ is tricky stuff but wouldn't the code bases they're trying to convert be of large proven mature projects?
They want to introduce it into Android.