Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming Google

Can Google's New Programming Language 'Carbon' Replace C++ Better Than Rust? (thenewstack.io) 185

Posted by EditorDavid from the Carbon-neutral dept.
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."
This discussion has been archived. No new comments can be posted.

Can Google's New Programming Language 'Carbon' Replace C++ Better Than Rust? More

Can Google's New Programming Language 'Carbon' Replace C++ Better Than Rust?

Comments Filter:

  • Prediction: (Score:5, Funny)

    by know-nothing cunt ( 6546228 ) on Sunday July 24, 2022 @01:43PM (#62729742)

    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)

      by rudy_wayne ( 414635 ) on Sunday July 24, 2022 @02:29PM (#62729876)

      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.

    • Or maybe Pyrolyzer, because you end up with nothing but carbon?

    • 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].

  • Am I right?

    • 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.

      • 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.

        • 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)

          by angel'o'sphere ( 80593 ) <angelo.schneider ... e ['oom' in gap]> on Sunday July 24, 2022 @07:06PM (#62730584) Journal

          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)

        by Misagon ( 1135 )

        > 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.

      • Swift also sounded like it's intended to be cross platform...

      • Except that Swift and Objective-C have nothing to do with each other except utilizing { and } - (* facepalm *)

    • It's compiled Java.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday July 24, 2022 @01:46PM (#62729750)
    Comment removed based on user account deletion

    • Re:Maybe but... (Score:5, Funny)

      by UnknowingFool ( 672806 ) on Sunday July 24, 2022 @02:10PM (#62729820)
      But we need another language [xkcd.com] because . . .

    • Re:Maybe but... (Score:5, Insightful)

      by Brain-Fu ( 1274756 ) on Sunday July 24, 2022 @02:58PM (#62729942) Homepage Journal

      “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

        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.

      • 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.

        • 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.

          • 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.

      • It has some specific benefits over C/C++ but those come with some distinct costs.

        Care to elaborate?

    • 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)

        by PCM2 ( 4486 )

        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?

      • Google doesn't use much of Boost.
      • Is Carbon really more interoperable with C++ than for example D? It seems to me that they have the same limitations when it comes to accessing code kept as templates.

        • 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

    • A safe subset is planned to be created somewhere down the line.

  • Says no.

    But a whole lot of new jobs will be created soon, specializing on it.

    • Re: (Score:3)

      by tgibson ( 131396 )

      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)

        by dyfet ( 154716 )

        Soon?? Recruiters are already looking for people with 10+ years experience with Carbon...

    • 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...

    • 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

      • 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.

      • 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?

        • 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)

        by HiThere ( 15173 )

        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.

    • Thank you! I thought I came up with it, and it already has a name! Betteridge's law, and it applies to a significant number of Slashdot articles.

  • 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.

    • 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];

      • "Memory safety" my ass:

        void add_friends(std::vector/attendee/ party_list} {
        for (auto person: party_list) {
        if (person.has_friend()) {
        party.insert(party.begin(), person.get_friend());
        }
        }
        }

        (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)

          by Z80a ( 971949 )

          I imagine there is a cat and mouse game between the lameness filter devs and the swastika dude

        • (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 "&lt;", etc., it's HTML 101.

          • 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

            • 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)

        by HiThere ( 15173 )

        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

        • 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)

            by HiThere ( 15173 )

            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.

        • 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.

      • 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.

        • 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.

      • 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)

      by splutty ( 43475 )

      But my own prediction is this gains zero traction and is pretty much dead by this time next year.

      It's Google. So even if it's not. It'll be canceled soon after.

      You're really shooting fish in a barrel here! :)

    • Is it me or does most of what comes from Google lately seem to be just PR stunts? Quantum Supremacy, Sentient AI, now this...

  • This (Carbon) is their internal pet project and they need to release it publicly to put a feather in their cap of accomplishments during annual performance reviews. It's just another project that's evolved "enough" that Google has permitted its disclosure.

    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

    • The arguments against C++ (committee and bureaucracy)...

      I dunno. New C++ releases are coming thick and fast lately.

      (Every couple of years or so)

  • Who needs standards in the times of "living standards"? The only available implementation will be the standard.

  • It's just an idea at this point (Score:3)

    by Dutch Gun ( 899105 ) on Sunday July 24, 2022 @02:05PM (#62729804)

    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)

      by HiThere ( 15173 )

      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.)

  • 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)

    by Junta ( 36770 ) on Sunday July 24, 2022 @02:27PM (#62729872)

    Guess you could say I'm carbon neutral

  • No. Java and C# tried (Score:5, Insightful)

    by Viol8 ( 599362 ) on Sunday July 24, 2022 @02:34PM (#62729886) Homepage

    ...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?

    • Go replaces C++ for server code. They want Carbon to replace C++ in Android.

      • Go hasnt replaced anything anywhere other than inside Google and with a few fanboy outfits.

        • Kubernetes is written in Go.

  • Standardization, stability, and backwards compatibility is why C/C++ are still around. So they want to do a new language with a modern approach to setting the API and backwards compatibility by open committee. This won't end well regardless of how good the initial design may be, it will be overrun by API political fights in short order.
  • Especially not Google with its ADHD mindset.

    • Re: (Score:2)

      by mccalli ( 323026 )
      Where do you think C came from? Angels and unicorns?

      • 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)

      by HiThere ( 15173 )

      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)

    by freax ( 80371 ) on Sunday July 24, 2022 @02:56PM (#62729932) Homepage

    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?

    • D introduces some awesome language features, its templating/meta programming abilities are fantastic. However it will never be a replacement for C++, between the multi headed monster that is memory management in D, limited c++ link compatibility( D is single inheritance, full compatibility would require multi-inheritance atleast for imported classes), poor early decision in development(D class member functions are virtual by default rather then final by default). And before its brought up, GC isn't necess

  • perpetual instability (Score:3)

    by dltaylor ( 7510 ) on Sunday July 24, 2022 @03:01PM (#62729944)

    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++.

    • 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

  • 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

  • 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.

  • "Mush have 5+ years experience in Carbon" - 2022

  • But wait (Score:3)

    by timelorde ( 7880 ) on Sunday July 24, 2022 @03:32PM (#62730040)
    Hasn't "Carbon" already been used?

    https://en.wikipedia.org/wiki/Carbon_(API)/ [wikipedia.org]

    Copywrited? Trademarked? Notify the lawyers!

  • 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++++ ? :-)

  • Also, we really got too many programming languages: https://www.youtube.com/watch?... [youtube.com] soon everything will be a incompatible Spagetti mess :-/

  • 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)

    by Opportunist ( 166417 ) on Sunday July 24, 2022 @04:53PM (#62730310)

    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

  • Finally acknowledging that there has to be a workable migration path.

    Took long enough.

  • Huh? (Score:2)

    by jythie ( 914043 )
    So... are they really complaining that C++ is too stable and consistent, and thus want to replace it with something more pythonic in its lack of consistency across years? Languages SHOULD be slow to change and not subject to the whim of random contributors, there is plenty of room for things like that in nice optional libraries.

  • It's all been downhill . . . (Score:4, Insightful)

    by Patrick May ( 305709 ) on Sunday July 24, 2022 @06:03PM (#62730470)
    . . . since Lisp. Let's just start using it again.

  • 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.

  • 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.

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close