47 ms·

Carbon Language: An experimental successor to C++

• Frankgerlach 4y ago
  Creating a "memory safe C++" is not too hard if you think about it. Here is my attempt, since 2011: http://sappeur.ddnss.de/ http://sappeur.ddnss.de/ Works nicely, unlike the Java Behemoth.
• optimuspaul 4y ago
  This is interesting. I've been relearning C++ after not using it for 25 years. It is hard, I was a Java dev for years, now Python with some Golang. Carbon looks much easier to take up.
• dleslie 4y ago
  I was interested and intrigued, but then: // A dynamically sized array, like `std::vector`. var circles: Array(Circle) = ({.r = 1.0}, {.r = 2.0}); Yegads, they've put effort into ensuring API and ABI compatibility with C++, but they've gone and decided to change the meaning of nouns for basic types?! Why, just why would introducing that obvious footgun be appealing? It raises the concern that the language is full of other arbitrary choices hiding dangerous footguns. Edit: Strangely, their test suite makes it look like Array is bounds checked and fixed size; there is no test for resizing: https://github.com/carbon-language/carbon-lang/tree/trunk/explorer/testdata/array https://github.com/carbon-language/carbon-lang/tree/trunk/ex...
  • mda 4y ago
    Why is it an obvious footgun?
    • dleslie 4y ago
      A developer familiar with C++ may believe it to be a fixed length container (perhaps with automatic bounds checking[0]) and treat it as such in memory/security/performance critical sections. 0: https://en.cppreference.com/w/cpp/container/array/at https://en.cppreference.com/w/cpp/container/array/at
      • xigoi 4y ago
        And if they named it “vector”, a developer familiar with mathematics might believe it to be a vector.
        • bmacho 4y ago
          Which is not a footgun.
          • Banana699 4y ago
            It actually can be, mathematical vectors gaurantee for example that x+y == y+x for all x,y, but no such gaurantee can be ever made on the user-defined operator+, indeed you can't even gaurantee that it is defined to begin with, let alone in the manner prescribed by linear algebra.
        • dleslie 4y ago
          The language is designed to replace, by progression, C++ for C++ developers. Mathematicians are probably better suited to using R, Julia, Octave, or Wolfram.
    • deleted 4y ago
      [deleted]
  • yakubin 4y ago
    It's std::vector that was weirdly named. In plenty of codebases "Vector", particularly gamedev and scientific, will mean the mathematical object with that name. Other languages don't need to replicate this mistake.
    • dleslie 4y ago
      And yet it is the name used in C++ code for a variable length container of contiguously stored data.
      • marssaxman 4y ago
        This is intended to be a different language, is it not?
        • dleslie 4y ago
          Not wholly different; it appears to be intended to interop with, and progressively replace C++ in existing projects.
    • deleted 4y ago
      [deleted]
    • cnity 4y ago
      True, though in OP's defense I don't know if I've ever seen a language refer to a growing list of entries as an "array".
      • linkdd 4y ago
        Well, the data structure is called a dynamic array
        • cnity 4y ago
          I don't see any reference to it in the GH readme, but I do wonder what they call actual arrays (as in, fixed size allocations of memory that store a contiguously typed value).
• superkuh 4y ago
  C++?? versions are the experimental successor to C++. A new language that the old C++ compilers cannot compile every 3-4 years.
  • throwaway744678 4y ago
    Backward compatibility works the other way: new compilers can still compile old code.
• bravogamma 4y ago
  Based on my quick read, “Why build Carbon?” section calls out just 1 problem with C++ which is the developer experience. Agreed. However Carbon seems to do a whole lot more than DevEx. It’s practically a whole new language that can interop with C++. I don’t see the point in that. Would be great if someone pointed out why I should change my mind.
  • mda 4y ago
    They have a separate document about difficulties improving C++: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
• vitno 4y ago
  It's not immediately obvious from this page and GitHub org, but this is a Google led project. It's led by Chandler and the c++ toolchain team. I have no idea of it's endgoals or how open to non-Google ideas it will be.
  • epage 4y ago
    > this is a Google led project This doesn't give me much confidence if its Corporate governance rather than open governance.
    • vitno 4y ago
      The governance of the project is not immediately clear to me, and I have to assume that the Google team is working in good faith. That team cares a lot about C++ and its future. They are obviously aware of this stigma. I also think that Google is pretty bad at open source governance though :/ Disclosure: Former Google engineer who worked sorta adjacent to some of those people.
      • chandlerc1024 4y ago
        FWIW, our governance structure is here: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/evolution.md#governance-structure https://github.com/carbon-language/carbon-lang/blob/trunk/do...
        • vitno 4y ago
          Hahaha, I really like the "painter" terminology. A+
        • runevault 4y ago
          Huh looking at that page and saw Kate Gregory is involved. She's someone who, as a mostly outsider who dabbles in C++ occasionally, seemed incredibly dedicated to seeing C++ thrive and people come to understand the language. Her involvement here seems like a huge positive to me, but maybe that's coming from a place of ignorance.
• hobo_mark 4y ago
  Looks like this experiment has been going on for a couple of years, a bunch of familiar (internet-familiar, have met Chandler a couple of times but do not know any personally) names were secretly working on it, and it was only made public a few days ago: https://github.com/carbon-language/carbon-lang/pull/1363 https://github.com/carbon-language/carbon-lang/pull/1363
• epage 4y ago
  It seems that the goal is a new language with full interop with C++, kind of like Zig's interop with C. - I wonder how much baggage had to be maintained for interop. If some of it could be isolated, how did they do it? - Does this fall into any of the traps that D initially did where it allowed C interop but was, by default, more limited in what C environments it could run in or is this as flexible as C++ for environments? As for the language itself, I've not had a chance to dig into it too much but I am sad to see that it uses explicit local inference by replacing the type name with `auto` rather than eliding the type completely [0]. While it has its pains at times, this is something I've come to enjoy in Rust. I also didn't see mention of tooling. Having out-of-the-box build, test, and code formatting would be a big help for establishing community standards / practices, even if the build/test tool might get limited when having to do C++ interop. At least for pure-Carbon libraries it would be a big help! > Once we can migrate code into Carbon, we will have a simplified language with room in the design space to add any necessary annotations or features, and infrastructure like generics to support safer design patterns. Longer term, we will build on this to introduce a safe Carbon subset. This will be a large and complex undertaking, and won't be in the 0.1 design. Meanwhile, we are closely watching and learning from efforts to add memory safe semantics onto C++ such as Rust-inspired lifetime annotations. I'm a bit skeptical if they push off lifetime annotations too far. [0] https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/type_inference.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
• deleted 4y ago
  [deleted]
• mepian 4y ago
  It's a shame a stable ABI is declared as one of the non-goals, C++ is painful enough to integrate with other languages.
  • beached_whale 4y ago
    ABI stability is an unstated goal of c++ and holds it back by preventing meaningful change or fixing of issues. This is good.
  • gpderetta 4y ago
    Apparently this is a google or google-adjacent project. Google was one of the most vocal committee members in favour of breaking ABI stability, so it is not surprising.
  • kllrnohj 4y ago
    C++'s current unwillingness to specify a stable ABI (or even state that ABI stability is a goal) but also have the standard libraries avoid breaking the ABI is a worst of both worlds currently. And the refusal to break the ABI adds overhead to things like std::unique_ptr which isn't really great. This paper goes into the details https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...
    • yakubin 4y ago
      Also, the unfortunate associative containers and std::regex.
  • lenkite 4y ago
    A stable ABI can effectively kill a language. https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/
    • saagarjha 4y ago
      (At Google, it’s definitely useful to others.)
• cogman10 4y ago
  If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including templates, to minimize or eliminate runtime overhead. In otherwords, what carbon can do that Rust can't do, is take a C++ class with a `foo` method and call that method. Or create a class with a `foo` method and call that method from C++. Probably one of the biggest hurdles to get over in C++ interopt. Most don't do that, instead you'd make a C function binding and struct and move data/invoke functions through that.
  • dleslie 4y ago
    Interestingly enough, Chicken Scheme has a library that allows for interop with C++ to this degree: http://wiki.call-cc.org/eggref/5/bind#c-notes http://wiki.call-cc.org/eggref/5/bind#c-notes
    • imaltont 4y ago
      I believe Clasp has a pretty good C++ interface as well for Common Lisp.
      • dleslie 4y ago
        It looks superior to Chicken's, albeit requiring more initial configuration: https://clasp-developers.github.io/clbind-doc.html https://clasp-developers.github.io/clbind-doc.html
        • imaltont 4y ago
          Well, they are different languages made for different things. Clasp was specifically made because the author had a bunch of C++ code for his research projects, but wanted something more high level/simpler to implement things in. He landed on Common Lisp but none of the implementations had good C++ interop, so he made his own. Can recommend Christian Schafmeister's (creator of clasp) talks on it, it's interesting stuff. In particular his talk on an LLVM Conference.
• alok-g 4y ago
  Awesome! I was looking for an alternative to C++ that cleans it up!
• sparkie 4y ago
  I'm still waiting on SPECS (1998) (https://users.monash.edu/~damian/papers/HTML/ModestProposal.html https://users.monash.edu/~damian/papers/HTML/ModestProposal....) But I don't think a re-sugaring of syntax is enough to make people switch.
• ansible 4y ago
  From the end of the safety document: > Overall, Carbon is making a compromise around safety in order to give a path for C++ to evolve. C++ developers must be comfortable migrating their codebases, and able to do so in a largely automated manner. In order to achieve automated migration, Carbon cannot require fundamental redesigns of migrated C++ code. While a migration tool could in theory mark all migrated code as unsafe, Carbon should use a safety strategy that degrades gracefully and offers improvements for C++ code, whether migrated or not. > That does not mean Carbon will never adopt guaranteed safety by default, only that performance and migration of C++ code takes priority, and any design will need to be considered in the context of other goals. It should still be possible to adopt guaranteed safety later, although it will require identifying a migration path. That's very interesting and pragmatic. It would be interesting if they can eventually come up with the same level of safety guarantees via a different path than Rust's borrow checker. ------------- Since one of their goals is to automatically translate modern C++ to Carbon, I do wonder how well that is going to work in general. I definitely welcome an alternative to C++ that would be easier to read and understand. That would be a benefit to the world.
  • jeffreygoesto 4y ago
    The borrow checker is a pretty smart solution pushing checks to compile time and have efficient runtime, so yes, it would be interesting to see if there is an even better alternative. But you can't beat that kind of safety into an old C++ code base, so I am pessimistic for retrofitting.
  • klodolph 4y ago
    This is also how Meta got Hack. It's not like PHP is unsafe to begin with like C++, but the language does have a ton of problems, and Meta's massive codebase could only be migrated to another language gradually. Hence, Hack. Better language, better tooling, more productive programmers. Note that unlike Carbon/C++, Hack is backwards-compatible with PHP. So the migration is somewhat more gradual.
  • MR4D 4y ago
    I wonder what would happen if Security became a compiler flag? For instance, just like the -O1 or -O3 flags work for optimization, something like a -S1 or -S3 would be really useful. To me, there are lots of times when I just need to get an idea into code. Then there are times when I need to make sure that code just works™. Having different compiler flags would really make that nice, and for devops, allow anything pushed to production have to complete a -S3 successfully first.
• pipeline_peak 4y ago
  All these C++ "successors" that do nothing but change the syntax sugar and find ways to operate with C++ are really tiring to read about. I seem to be the only one on the planet that doesn't think the language needs to be replaced.
  • bestouff 4y ago
    I'm as tired as you by these cosmetic successors. But for my part I think C++ has already been replaced, and to great benefits. I couldn't thank the people building Rust enough.
    • rvz 4y ago
      I still haven't seen a cross-platform production level GUI app written in Rust. All the time, it is C++ these companies use for these apps, especially having millions of users and generating multi-millions or hundreds of millions of dollars.
      • jeltz 4y ago
        Many cross platform GUI apps have been written in C, JS and Java too. The ability to write GUI apps does not really seem that unique to C++.
        • adastra22 4y ago
          That’s not the claim being made.
      • mustache_kimono 4y ago
        "I still haven't seen a production level numerical weather prediction app written in Rust. All the time, it is Fortran the government uses for these apps,..." I vacillate as to whether the best response is: "Who cares?" or "give it time"? First, if C++ actually is better for GUI apps, then more power to C++ (do you have some evidence this is the case?). That doesn't mean their aren't other niches to fill for other languages, like Rust. Next, Rust is a relatively new language. It may end up that it's really great for GUI apps, but again it doesn't have to be. It can be great at other things.
• deleted 4y ago
  [deleted]
• sebastianconcpt 4y ago
  Does it help in any way with memory management or it keeps that burden loaded in the developer's back?
• secondcoming 4y ago
  Interesting. It will obviously take off _because Google_ but since they're heavily influcened by the Rust syntax, why not just learn Rust instead. They'll need to get it into Compiler Explorer so people can really look at codegen rather than porting small programs.
  • visheshdembla 4y ago
    https://carbon.godbolt.org/ https://carbon.godbolt.org/
    • secondcoming 4y ago
      tremendous!
  • saghm 4y ago
    > since they're heavily influcened by the Rust syntax, why not just learn Rust instead Interestingly, when looking at their code samples, the vibe I get is more "Go++". Using `var` for variable declarations, letter casing for visibility, explicit returns even at the end of functions, using the "package" keyword for namespacing, etc. I do see some superficial syntactic similarity to Rust, like using `fn` for functions and `->` to annotate return types, using `:` for type annotations for variables, and semicolons seeming to be required at the end of lines, but overall it doesn't really _feel_ that much like Rust to me, I think due to how imperative it seems. Given the use of `class` and `let/var` seeming to be const versus mutable bindings, I'm wondering if the Rust resemblance is actually just transitive through more of a resemblance to Swift, although I don't know Swift well enough to know if this is an accurate explanation.
    • Erlangen 4y ago
      > like using `fn` for functions and `->` to annotate return types `->` syntax is included in C++11 standard, named "trailing return type", but its adoption seems to be very slow. `auto f() -> int { return 42; }`
      • 4y ago
• rvz 4y ago
  > Interoperate with your existing C++ code, from inheritance to templates Very important. A C++ alternative and successor needs to be compatible with C++. The rest of these so called C++ alternatives are either rewriting everything in their own language and causing chaos with their own incompatibilities with their language features and realising that it wasn't a good idea after all to do such rewrites after being sold vacuous promises and language feature snake oil, but only to show pretty syntax sugar. Unfortunately, the hype squads will just attempt to drown out other alternatives like this one; even if it works with the existing C++ ecosystem.
• beeforpork 4y ago
  Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give rise to. Because then I'd rather use Rust instead, which then feels like the real thing(tm). [EDIT: If you think about downvoting, maybe answer instead as I am genuinely interested in this syntax question. I am not trying to be negative, it was just an observation and a question.]
  • notriddle 4y ago
    It's not just Rust syntax. `name: Type` is the syntax used in TypeScript and Python type annotations (also Ocaml, which is probably where Rust got it from). Golang drops the colon, but still keeps the name first. As for what's wrong with `Type name(constructor, args)`? A lot of tooling wants to be able to parse "mostly-valid C++", like IDEs and compiler diagnostics. Sure, once clang's type inference is finished, the lexer hack and most vexing parse aren't problems, but when the program isn't complete, parsing isolated fragments is impossible, and that limits the amount of useful tooling the language can have.
    • beeforpork 4y ago
      OK, I see. Yes, C and C++ syntax is definitely ambiguous without semantic analysis. Maybe this could also be explained somewhere.
    • cyber_kinetist 4y ago
      And to add, the `name: Type` syntax is not just a modern fad, don't forget the OG language that did this: Pascal! (https://en.wikipedia.org/wiki/Pascal_(programming_language) https://en.wikipedia.org/wiki/Pascal_(programming_language))
    • c-cube 4y ago
      The syntax `name: Type` is also friendlier to type inference as you generally have a token indicating a declaration. If you have `var x: Type = …` then you can just omit the type and let inference do its job. Even better, when you start having more complex patterns on the left-hand side of `=`, you can type annotate them as you want. Hypothetical syntax would be: var (x: f32, y, [z1,z2,z3]) = SomeExpression(); That's harder to do when you have a type declaration on the left imho.
• donkarma 4y ago
  https://xkcd.com/927/ https://xkcd.com/927/
• m4nu3l 4y ago
  I had been thinking about something like this for a long time. There is just too much C++ code out there but C++ (despite many efforts by the standard committee) is still too verbose and hard to make sense of in many cases. So I thought "why not designing a new language that is compatible with C++?"
• sam0x17 4y ago
  why camel-case functions tho :(
  • zeotroph 4y ago
    Indeed, from Python to Rust and newer C++ codebases you usually see CamelCaseClasses (or structs) and then snake_case for functions methods etc, which improves readability. CamelCaseForEverything is such a waste, maybe they use it for implicit public/private as in Go? And maybe to please existing Go or Java users?
    • Narishma 4y ago
      That's PascalCase. camelCase is like this.
      • palata 4y ago
        I call them UpperCamelCase, lowerCamelCase, Upper_Snake_Case, lower_snake_case.
• outside1234 4y ago
  We already have this with an open foundation: Rust No thanks
  • cyber_kinetist 4y ago
    They have an entire FAQ subsection pointing out some practical reasons why one might choose Carbon instead of Rust. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust https://github.com/carbon-language/carbon-lang/blob/trunk/do...
  • zeotroph 4y ago
    On the road map they have Broaden participation so no organization is >50%, so this has a good chance of not becoming Swiftoogle-Lang. Also, under "Why not Rust?" 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.
  • Rebelgecko 4y ago
    How straightforward is interop between C++ and rust?
• underdeserver 4y ago
  If you want to me to buy it, show me an automatically translated C++ snippet.
• AndruLuvisi 4y ago
  Why do so many new and improved languages still lack tail calls?
  • JonChesterfield 4y ago
    It's moderately annoying to implement because it messes with the calling convention in architecture dependent ways. So it isn't an IR transform, it's N lowerings for N architectures. Clang and llvm understand them, and you can require them from the front end, but the cost is some backends will hard error on them as unimplemented.
    • throwaway17_17 4y ago
      Just to clarify, are you saying that a language’s calling convention is implemented differently per architecture? Or is it that the tail call implementation needs to be implemented in different ways per architecture and that would mess with the required calling convention?
      • JonChesterfield 4y ago
        Calling convention covers where values are placed in memory (or stack or registers) by the caller so that the callee can find them. There can be N of these as long as caller/callee pairs agree sufficiently. The instruction set you're compiling to influences the cost of different choices, e.g. how many and which registers to use. Tail calls mean reusing memory (notably the stack) and arranging for there to be no work to do between the call and the return. E.g. if arguments are passed by allocating on the stack, you can't deallocate after the call, so you have to make the stack look just right before jumping. If you've got multiple calling conventions on your architecture, they each need their own magic to make tail calls work, so you might have 'fastcall' work and 'stdcall' error. Iirc I implemented it for a normal calling convention on one arch and didn't bother for variadic calls. I suppose one could have a dedicated convention for tail calls as well, I just haven't seen it done that way. Usually the callee doesn't know and can't tell whether it was called or tail-called.
• Erlangen 4y ago
  Its github repo has a very interesting doc on when it's the right time for Carbon language to go public. https://github.com/carbon-language/carbon-lang/commit/b8750e6c4bf1ff767a1fb8d4d658e87d8cc96434 https://github.com/carbon-language/carbon-lang/commit/b8750e... > Broader field experience required > Sustained interest to use Carbon from multiple organizations and individuals > Prototype implementation > Demonstration of potential > Learning material > Prepare for new contributions and feedback > Launch event > Relationship to C++ > Perception of ownership by a single organization Is this post considered as a step towards going public?
  • chandlerc1024 4y ago
    It was made public at CppNorth, a C++ conference, earlier today. The page you mention is a bit out of date though, you can find the update to our plans here: https://github.com/carbon-language/carbon-lang/commit/4aa462c2ac38388019763dc9d3ce59ea4ff6fa89 https://github.com/carbon-language/carbon-lang/commit/4aa462...
• lenkite 4y ago
  Please let them make a proper interpreter for dev efficiency!
• saagarjha 4y ago
  (Speaking only for myself, I just watch from the sidelines and have no involvement) This seems like Google’s response to 1. Rust not being sufficiently “Go-like” (in the sense of the “The key point here is our programmers are Googlers, they're not researchers” quote) where C++ lets a bunch of people who are not really experts in the language write footguns that Google has to deal with when they cause problems at scale. They want a dumbed-down language (some would use words like approachable/safer/whatever here) for them so nobody will send in CLs with ”clever” code that causes headaches later. I guess they’ll need to have generics but I’m guessing that choices will be made to avoid introducing advanced type theory, functional programming, etc into the language. 2. Google uses C++ differently than everyone else who uses C++. In particular, they have a lot of statically linked code from a monorepo that gets recompiled all the time. This has caused them to put up proposals to “fix” the language that nobody else will support and don’t get adopted, because they break the ABI or backwards compatibility in ways that are unacceptable to the others who participate. It seems like this language is the result of that frustration and subsequent soft-withdrawal from the C++ WG. I haven’t looked at the design much yet beyond just the simple examples and I think it mostly looks reasonable, but I feel like Google designed this to solve their problems with C++ and is just throwing it out there if people are willing to adopt it because it’s there and Google says it’s good, just like how Go gained traction. Sometimes Google does make good things :) Some Go developers would say that about Go, I’m sure. But if you’re using this, it seems pretty clear that the needs of this will be driven by Google, and the above two points are probably things you should keep in mind as you watch it evolve.
  • zozbot234 4y ago
    My guess is that it's pretty much all about 2. They say explicitly in their FAQ that you should be using Rust, or any other well-established language, if not constrained by the need for deep, complex interop with C++ code bases. They're not positioning this as a "more approachable" alternative to Rust, only as one that sticks closer to existing C/C++ coding patterns.
    • sudosysgen 4y ago
      To be fair, for many many many people there is a requirement for deep, complex interop with C++. Even if you're getting started on a new project being able to easily leverage the C++ ecosystem could make or break it.
• no_wizard 4y ago
  A reasonable test of interop would be converting boost to carbon. Then you'd hit an enormous amount of edge cases and really be able to understand carbon's shortcomings, no?
• mihaic 4y ago
  Am I the only one that doesn't like this direction for the syntax? This was the main reason why I never got into Rust, it was just too different without any obvious reason. It's strange that I actually enjoy working with type annotated modern Python though. I'll now go away for a few years until the dust settles.
  • xigoi 4y ago
    The obvious reason is that C++ syntax is difficult to parse, for both machines and humans.
  • wiseowise 4y ago
    What exactly you don’t like about it?
    • mihaic 4y ago
      Just a lot of small things stand out: - function and variable types are harder to visually parse for me. The keyword to declare a variable and the type put the varible name in the middle for instance. - the "fn" keyword is terrible, just to save on characters. Honestly, any keyword should have vowels and is pronounceable. Python has "def", I would have been fine with "func" as well - type annotation for templatization make is hard to read where the real arguments begin (for me). I puts info on the type in another place than the variable itself. - "Mutable" feels like it should be all lowercase, to stand out. In general, I know there are areas to improve on C++ syntax, especially on modules, but some choices seem different just for the sake of difference.
      • zozbot234 4y ago
        It's pronounced "fun", they just didn't want to make it too explicit because coding isn't always fun.
        • ai_ 4y ago
          I always thought it was pronounced "ef'in". Like when you have to censor yourself in front of coworkers because of this ef'in code.
• danjoredd 4y ago
  Don't create a programming language to kill another language. That never works. Create a language that fulfills a specific purpose.
  • compiler-guy 4y ago
    Carbon is intended to kill C++ in just the same way as C++ is designed to kill C, Kotlin is designed to kill Java, and Dart is designed to kill Javascript. Which is to say, "Not at all".
    • Koshkin 4y ago
      Well, to be fair, "successor" can indeed be understood as "replacement."
  • Koshkin 4y ago
    This is rather deep, if you think about it. My gut feeling, coming from experience, is that the future lies with DSLs. A good programmer would mold the the general-purpose language he works with into a DSL fitting the problem at hand anyway (using whatever means available, e.g. macros or generics or both). Incidentally, the modern Lisps and C++ look the best in this regard.
• mlinksva 4y ago
  I don't see the name explained anywhere in the excellent FAQ and other documents, but I wonder if it a play on Rust/Oxidize/Oxidization -> Carbon/Carbonize/Carbonization. Only mention of those terms seems to be https://github.com/carbon-language/carbon-lang/issues/505 https://github.com/carbon-language/carbon-lang/issues/505 which seems like weak evidence against naming conjecture.
• pjmlp 4y ago
  The experimental successor to C++ is Circle. I guess now it is clear where Google's clang contributions end up going instead.
• hexo 4y ago
  Doesn't look much like C++ successor to me, at all. What's up with all those fns, and functions starting with uppercase?
• nikolay 4y ago
  Well, `returned var` is totally unnecessary - why didn't they borrow the syntax from Go?!
  • masklinn 4y ago
    https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p0257.md#named-return-variable-in-place-of-a-return-type https://github.com/carbon-language/carbon-lang/blob/trunk/pr... > Disadvantages: > - The syntax space of the return type is very crowded already, and this would add more complexity there rather than fitting in cleanly with existing declaration spaces within the body of the function. > - Likely to be an implementation detail and valid to use on a function with a normal return type in its forward declaration. This isn't obvious when placed in the declaration position, and it might well be unnecessarily added to forward declarations just because of its position. > - Removes the ability to both specify a specific return type and a pattern for binding parts of that object to names. Instead, the type must be inferred from the pattern. This ended up feeling like a deep and fundamental problem where we would lose important expressivity to disambiguate the return type from patterns. For example, when the return type is some form of sum type or variant, the pattern space is both especially attractive to use and fundamentally fails to express enough information to capture the type.
• Kukumber 4y ago
  This is the proper way to replace C++, being able to fully consume it Just like Kotlin did to Java The only viable alternative to C++ imo
• dvirsky 4y ago
  Why did they go to such lengths to obscure the fact that it's a Google project? I heard about it back when I was a Googler so I knew immediately what it was, but otherwise it was very hard to find any indication that this is a Google led project.
  • ccbccccbbcccbb 4y ago
    Must be avoiding the stigma of the broken promise not to be evil.
    • dvirsky 4y ago
      The thing is they have an excellent track record with runnig open source programming languages for over a decade. It's often claimed that Go succeeded only because it was sexy because it was Google. Why hide it here?
      • ccbccccbbcccbb 4y ago
        Being a benefactor doesn't trump being an abuser at the same time.
• Animats 4y ago
  Can C++ be machine-translated to Carbon? That would be useful. Translating C++ to Rust is too hard - the underlying data models are too different. What would be really useful would be something that intelligently translates pointer-based C++ code into a slice-based language. Every place there's an unsized array, something has to figure out how big it is and pass that info around. In the original program, that information had to be present in some form. The trick is finding it. That's probably not out of reach for a static analyzer today. Especially if machine learning is used to help find the usual idioms of C/C++. First find, then check.
• ape4 4y ago
  I know lots of languages are going with exactly saying the size of your numbers like "i64". In C/C++ you would say "int". Of course sometimes you want to declare and exact size but for a regular integer it seems simpler to say just "int".
• ArrayBoundCheck 4y ago
  This is the 3rd language I know about that google created. I have no idea why they don't use rust with their C++ code base and I don't know why they made this instead of use zig which actually brings something new to the table. Overall I don't see myself using this. 0/3 google
  • compiler-guy 4y ago
    There is an entire document which explains why they can't use rust or zig. The short version is that for their particular usecase they need really close ties to C++. "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. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead."
    • ArrayBoundCheck 4y ago
      I guess I'll rewrite my original comment here to clarify I don't know why google created this language. It offers nothing new and I can't see why they'd use this over rust when rust can be used. I don't see why they use this over zig since zig can certainly be used where this language is meant to be used. Zig actually brings something new Overall google is 0/3 on creating languages that people want to use. Maybe go is useful but I haven't seen enough proof
• gigatexal 4y ago
  From the syntax alone it looks a bit more approachable than vanilla C++.
• gwbas1c 4y ago
  I wish they spoke more about their ideas regarding the memory model. For me, that's usually the first thing I want to know about a new language. (I initially assumed they had some syntactic sugar for smart pointers.)
• twen_ty 4y ago
  No. No. No. This reminds me of Dart - another big company thinking they can invent a new language to tackle old language problems. This is not the way to improve C++ - because this path already exists, either as D or if compatibility or OO model isn't an issue, Rust. C++ has been improving slowly but surely - just remember that 90% (heck even more) of C++ issues stem from the hell that's compatibility with C and that's both a blessing and a curse.
  • piperswe 4y ago
    Same big company actually - Dart and Carbon are both Google projects
  • ironman1478 4y ago
    Google is in the business of making software in exchange for money and they have internally determined that the way C++ is and the direction C++ is headed isn't good for them. They don't "care" about C++, they care about running a business. They have determined that C++ as it is isn't sufficient and the direction its going is not acceptable to meet long term goals, whether that be implementing new products or maintaining existing software. Google has wholly unique software organization problems that very few other companies probably have. If you've seen their cppcon talks, you'll see that the changes they want are not what the committee (or even the general c++ community) focuses on (for example, I couldn't care less about ranges). For example, they want to make changes to unique_ptr because the inefficiencies in the ABI cause performance issues and probably can be tracked to additional cost per month. They couldn't make these changes without changing ABI. At google scale, small inefficiencies add up so fast. I have no doubt they looked at D and saw that it wasn't feasible (for whatever reason) and they already stated why Rust is not sufficient. They wouldn't make this decision arbitrarily and we are not privy to all the meetings that went into the decision making process.
    • ehzy 4y ago
      Do you mind sharing a reference for the changed Google wanted to make to unique_ptr? I tried searching but couldn't come up with the right set of keywords to find anything relevant. TY!
• StillBored 4y ago
  I've seen this fn/var argument a few times, but its a really that much harder to write a parser that can intuit the difference between a function/variable/statement without explicitly putting function/var/let/etc all over the place? I like the verbosity of a language like pascal, but I just find it jarring in a C replacement these days. (and rust's structure definitions/etc I just find needlessly verbose for the way I use C structures). C is nice because its fairly easy to mentally parse (C++ less so) vs some of the alternatives, while still being extremely concise.
  • xigoi 4y ago
    The C way makes it hard to find the name of the function (or even tell that it's a function declaration) when the return type is long. std::vector<std::unordered_map<std::string, std::pair<std::string, std::string>>> foo(std::vector<std::vector<int>> x, std::unordered_map<std::string, std::string> y);
    • StillBored 4y ago
      I said C++ was diff, but how about: using namespace std; typedef vector<unordered_map<string, pair<string, string>> foo_bar_xref; foo_bar_xref foo( vector<vector<int>> x, unordered_map<string, string> y); not sprinkling std:: everywhere helps with readability, but so does defining a couple types used frequently, especially if they are particularly verbose. And of course the parser doesn't really have a problem with this, so your editor should be able to find it with its 'goto declaration' function. I don't feel pity for people who chose to use editors/IDEs that make this difficult.
      • xigoi 4y ago
        > not sprinkling std:: everywhere helps with readability I agree, but most C++ programmers don't :/ > And of course the parser doesn't really have a problem with this, so your editor should be able to find it with its 'goto declaration' function. C++ syntax is Turing-complete, so due to the halting problem, finding the declaration can take a long time, potentially unlimited in pathological cases.
• nikeee 4y ago
  Looking at this [0] news from about a month ago, the Chrome team showed that they are trying to bring Rust to the table. However, their wording was: > The Chrome security team is working to make a cross-platform memory safe language available to Chromium developers. This document describes how to use that language in Chromium. The language, at least for now, is Rust. Could this mean that the "at least for now" part might hint to the language discussed in this thread? Memory safety seems to be a core goal of Carbon [1]: > Safer fundamentals, and an incremental path towards a memory-safe subset This approach could make sense, looking at their large C++ code base in Chrome. [0]: https://news.ycombinator.com/item?id=31830020 https://news.ycombinator.com/item?id=31830020 [1]: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang
  • tialaramex 4y ago
    Sure, the Chrome security team have got a problem, Rust has a solution, if somebody comes along with a better solution why wouldn't you. But, right now Carbon doesn't have a better solution, it only has an ambition to build an incremental path toward being able to be a solution. Importantly it has an ambition but it has no proposal for how to get there. There are other safe languages, but AFAIK none of them launched with "Eh, we'll do safety later, I'm sure we don't need to start with it". The ones I'm thinking of all began with their safety principles and then they added cool features which were inspired by those principles. I reckon that even if that's not directly causal, it means the culture associated with these "We'll do safety later" languages doesn't prioritise safety highly enough. So ambition or not, they aren't going to put the hard work in to make it actually happen.
    • pkasting 4y ago
      I work on the Chrome team. Safety is not the only goal for the codebase. There's also things like readability, maintainability, performance, and correctness. Finally, there's the need to chart a course towards how you get there. Rust provides many of these, but not much of an incremental path there. Carbon aims to provide many of these, but not as much safety as Rust (likely, even in the future). The upshot: there are tradeoffs, and we'll need to watch our options and make continual decisions as to the best courses of action. Such courses may differ by area of the project; it's possible we might choose to write some hardened services in Rust communicating via Mojo with mixed C++/Carbon code.
• smallstepforman 4y ago
  Not for gamedev or protocol stacks since no pointer arithmetic …
  • renox 4y ago
    I'm not convinced that pointer arithmetic is necessary for gamedev: Odin (which has swizzle built-in!) has pointers but no pointer arithmetic.
• kccqzy 4y ago
  There was apparently a presentation by Chandler today on Carbon: https://twitter.com/code_report/status/1549383435642445824 https://twitter.com/code_report/status/1549383435642445824
• mountainriver 4y ago
  This is a really great idea, I love rust but it’s lack of good c++ interop has kicked me more than once
• anarazel 4y ago
  Requiring Google's CLA to be signed to contribute seems pretty limiting...
• germandiago 4y ago
  Wow, this one looks really interesting. It is 100% interoperable?
• Barrera 4y ago
  From the README: > Interoperate with your existing C++ code, from inheritance to templates Somewhere in the docs (can't remember where) is a link to a Rust/C++ interop project sponsored by Google, Crubit: https://github.com/google/crubit/blob/main/docs/design.md https://github.com/google/crubit/blob/main/docs/design.md In case it's not clear, Carbon is also at the moment a Google project. There's not much in the Crubit README (although there is a warning not to use it), but the docs directory has some interesting stuff: > The primary goal of C++/Rust interop tooling is to enable Rust to be used side-by-side with C++ in large existing codebases. https://github.com/google/crubit/blob/main/docs/design.md https://github.com/google/crubit/blob/main/docs/design.md It's not entirely clear whether this interop is to work as envisioned for Carbon (source level?) or some other approach.
• throwaway03423 4y ago
  Carbon Team, thanks for sharing, I will likely use this if I need to bridge with CXX libraries. Also thanks for adding sum types, and pattern matching, is there anyway you could get the dart team on board? They seem to be averse to them and it's a big reason why I don't use the Dart/Flutter ecosystem.
  • timsneath 4y ago
    Au contraire! We're actively investigating them here on the Dart team. We're finalizing the spec here: https://github.com/dart-lang/language/blob/98335746fb7f2dedfa2b14709938027b0bf9a4f6/working/0546-patterns/patterns-feature-specification.md https://github.com/dart-lang/language/blob/98335746fb7f2dedf...
  • munificent 4y ago
    > Also thanks for adding sum types, and pattern matching, is there anyway you could get the dart team on board? I'm driving the design of pattern matching for Dart. The entire language team is on board with them and we have a design that's pretty far along. It's really hard to integrate pattern matching into a language that wasn't originally designed for it, so it's taken a while to settle on a syntax that makes sense, but I think we're getting close. If you'd like to be involved, there is a category on the issue tracker for design discussions related to patterns and records: https://github.com/dart-lang/language/issues?q=is%3Aissue+is%3Aopen+label%3Apatterns https://github.com/dart-lang/language/issues?q=is%3Aissue+is...
• hartjer 4y ago
  Have you thought about rewriting it in rust? :3
• togs 4y ago
  I'm surprised C++ is still prominent. I thought Rust would have taken its place by now.
• sam_bristow 4y ago
  It's a minor thing, but I do find it odd that they use PascalCase for function names when the C++ standard library uses snake_case.
• jcranmer 4y ago
  Some quick notes about interesting features of the design: * Source file encoding is required to be UTF-8. Strings are UTF-8. No apparent provision for binary strings, but I haven't delved into the string API. * Retains the C/C++ definition of overflow of signed integers cannot overflow, unsigned can. That's o_O-worthy; the two should be aligned, and if they can't overflow, provide some form of wrapping integers as well. * Yay, tuples. * Struct type syntax is ... weird? {.name: String, .count: i32} * Expressions. Partial order for precedence (i.e., a | b << c is ill-formed instead of being parsed as (a | b) << c or a | (b << c). The Rust-style cast syntax I think I prefer, but ^x for bitwise not is o_O, and if a then b else c feels odd for a generally C-syntax language to use. Similarly using 'and' for logical and instead of &&. * var and let for declaring variables; one is constant, the other not--that's somewhat jarring. It seems that the : <type> is mandatory, and inferred type is : auto instead of letting it be omitted? Feels unnecessarily verbose to me. * No goto, nor labeled break and continue. Huh. Also, 'for (var name: String in strings)' is again feeling unnecessarily verbose... (Can break break out of an if statement, or does it have to be a loop?) * You declare "returned var c: Circle" instead of relying on named return value optimization. Again with the verbosity, although I haven't yet reached copy/move constructor stuff to understand how much automagic happens. * The [me: Self] syntax is weird. I'd like something closer to the C++ deducing this syntax or Rust's &self/&mut self, where the type of the this parameter is specified via the first argument rather than what feels like a somewhat-out-of-bounds information. * Mixin (aka multiple inheritance) is unspecified at this point. * The keyword for enums is "choice"? Really? * Name lookup retains the C/C++ rules of need-to-declare-before-use. Again, is this really necessary? It's fiddly... * The [me: Self] syntax appears to be a specific instance of the generalized syntax for generics, but only for method parameters, because generic types use () instead. Again, why differentiate from the C-family standard practice of <> for generics? Also, the : versus :! in generics strikes me as overdrawing the weirdness budget one too many times. Props for using something closer to a constexpr if than C++ SFINAE; SFINAE is not a design model I would carry forward in any future languages. * Stable ABI appears to purely be defined in C ABI terms. Sigh, can we get people on these language committees together to start thinking about post-C standardized ABIs? * Async, coroutine, lambda stories are unclear. * Error handling also unclear. (That's kinda important!) * Not clear from the main design document is how the distinction--if any--between trivial/nontrivial copy/move types work. There appears to be an explicit move operator (with obvious syntax ~x), so support for nontrivial move or immovable is better than Rust already, but the avoidance of a NRVO setup still makes me wonder what the actual story is here.
• guywithahat 4y ago
  Their C++ code example doesn't compile, it has too many "}" marks in the circles definition call. Truly the mark of an experimental branch
• dxuh 4y ago
  I just do NOT feel like using a language, that has explicitly stated, that you should not start a new project with it. Very few legacy projects will consider using Carbon, I would assume (If you have worked on one, you probably know that "legacy" is usually more than just the code) and then there are so few projects left that I see no chance of this really taking of. And in that case it will probably die soon as well, like many (most) other Google projects.
• Maursault 4y ago
  Why "Carbon?" I just want to known if I a missing something subtle... or if it is just C, the symbol for carbon. Developers need better and unique names for their products. I realize no one will care because no one is using it anymore, but Carbon was already taken by Apple for their Objective C API.[1] That both are pretty much in the same space with the same name is sure not to cause any confusion. [1] https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API)
  • feminintendo 4y ago
    I'm not following you at all. Carbon was an API for Mac OS X, not a programming language. It was a C API, not an Objective-C API. (Maybe you are mistaking it for Cocoa, which required Objective-C on 64-bit platforms.) What relationship does this have to the new Carbon programming language? Google did clobber another programming language with Go.[1] It was a truly a-hole move. [1] https://en.wikipedia.org/wiki/Go_(programming_language)#Naming_dispute https://en.wikipedia.org/wiki/Go_(programming_language)#Nami...
    • Maursault 4y ago
      > I'm not following you at all. Not even a tiny little bit? Really? First of all, apologies for my boneheaded mistake, but let me try to see if I can show you the problem. If everything, everything there is, was named "Tom," you can see how it might get confusing determining just what is being talked about. That is hyperbole, but it should illuminate why it is ambiguous to call two things by the same name, but it is even more so when these two things with the same name operate in the same space. But wait, you say, they are entirely different and unrelated! You think no one will be confused, because one Carbon is a programming language possibly based on C++ and the other is a C programming language API. Totally different, huh? In fact, they're in the same space, programming. One Carbon is a language, the other a application programming interface for another programming language. They're also more or less dealing with the same programming language. I realize C is not C++, but without C there would be no C++, so they are very strongly related, along with ObjC. Fundamentally, these languages are all C, the newer ones using the same syntax but with advanced features not found in C. Still C, if we're being handwavy, and we definitely are. So now, whenever someone mentions Carbon somewhere, like, "use Carbon!" That will be ambiguous due to this developer's unfortunate lack of nomenclature creativity. Does that help at all to reveal why a new programming language based on C++ should probably chose a unique name rather than recycle a name that is still in use to refer to a C API? Since Apple already chose Carbon for their C API, and since it is so well established, even if it is no longer used, and since it is just not that old, and it when it was current, it was everywhere Apple, then it takes priority. So the arbitrary name this developer chose will inherently cause confusion, inevitably, because another Carbon already exists in the programming space. Why not call it "Centigrade?" Or "lightspeed?" Because calling a C++-based language "Carbon" because it is based on C++ is not remotely as clever as Apple calling their C API Carbon because C is the symbol for Carbon, and not C++, which itself is a great name for a programminglanguage because it will never be confused with anything else, because afaik nothing other than C++ is called C++. Let me know if you need more explanation why Carbon is an unfortunate name for anything new in the programming world. If it was, idk, the name of a publishing company or something, it wouldn't matter. It only matters because these things are in the same space.
• billsnow 4y ago
  Seems neat, but it looks like the major thing is the syntax. Of course c++ syntax is insane and should be updated, but i cant shake the feeling that c++ developers secretly love it. Scanning c++ code for a seasoned c++ developer is like the bushmen of the kalahari scanning the african savanna.
  • dw-im-here 4y ago
    Because we're scanning for predators?
• n4jm4 4y ago
  Rust is good enough for HFT, Web rendering, and the Linux kernel but go ahead and add Carbon to the massive list of been-there-done-that. Pro tip: Don't try to migrate an entire catalog of functions all at once to Rust (or pick your favorite C++ alternative). Pluck off individual pieces and use FFI to bridge the gap. Remember, work incrementally.
• lilulo 4y ago
  If you enumerate all top level goals of the language, they all are satisfied by just staying with C++: . Performance matching C++, an essential property for our developers. . Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest. . A gentle learning curve with reasonable familiarity for C++ developers. . Comparable expressivity and support for existing software's design and architecture. . Scalable migration, with some level of source-to-source translation for idiomatic C++ code.
  • dymk 4y ago
    Migrating C++ code can be a major pain in the ass "At Scale", and designing C++ templates code that works intuitively but isn't just simple type replacement is an even bigger pain in the ass. Hence, a language that doesn't include things like SFINAE.
• deleted 4y ago
  [deleted]
• jb1991 4y ago
  > 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. Enough said! I agree.
• OnlyMortal 4y ago
  I read the title and immediately thought of the Carbon API that was used in Classic Macintosh and legacy C/C++ GUI apps on OS X. Obviously not…
• childintime 4y ago
  A detail that strikes me as odd, and an explicit deviation from Rust, is to indent with only 2 spaces. Dart does the same, but its justification is the (excessive) amount of indenting going on. It's often a struggle to match indents visually.
  • dw-im-here 4y ago
    Why not use a text editor that renders indents as whatever you want them to be?
• peter_d_sherman 4y ago
  >"Carbon aims to fill an analogous role for C++: JavaScript → TypeScript Java → Kotlin C++ → Carbon"
• synergy20 4y ago
  please at least do what rust|go can: generate multiple platform code easily, i.e. make the build tool cross platform friendly. one reason I use golang over c++ is the network, for c++ network socket Unix and Windows are totally different(winsock vs bsd socket), while golang works well at both OSes.
• dfgd 4y ago
  fdgdfg
• cppnext2022 4y ago
  https://youtu.be/omrY53kbVoA https://youtu.be/omrY53kbVoA
• tipseason 4y ago
  Tried to understand more with some basic examples. Wrote a getting started guide for fundamental syntax. Feel free to play around. https://tipseason.com/carbon-language-tutorial-syntax/ https://tipseason.com/carbon-language-tutorial-syntax/