14 ms·

Google Launches Carbon, an Experimental Replacement for C++

168 points by isaacfrond 4y ago

in9 4y ago
wasn't go supposed to be a replacement for C++?
- timbit42 4y ago
  No. It's more like a fast Python.
- vultour 4y ago
  I don't think one should consider any language with a garbage collector a replacement for C++. I love Go but in my opinion it serves a different purpose than C++ or Rust.
petre 4y ago
There's already a successor to C++. It's called D.
- timbit42 4y ago
  How does D's safety compare to Rust and Carbon?
debug-desperado 4y ago
Not a C++ programmer, but I'd like to ask: Are Carbon's goals for interop here sufficient for most libraries and frameworks, or will bridge code be required in most cases? I see this about exceptions, for instance: "Carbon may not provide seamless interoperability support for C++ exceptions. For example, translating C++ exceptions to or from Carbon errors might require annotations or bridge code, and those translations may have some performance overhead or lose information. Furthermore, if Carbon code calls a C++ function without suitable annotations or bridging, and that function exits with an exception, the program might terminate." https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/interoperability/philosophy_and_goals.md#non-goals https://github.com/carbon-language/carbon-lang/blob/trunk/do...
- sseth 4y ago
  I am guessing that this is less of a concern for Google. Per Google's C++ style guide : "We do not use C++ exceptions." So they are already not using that feature in their C++ code today. https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
  - debug-desperado 4y ago
    That’s what I was getting at. I hope they get some real feedback from Nvidia, AMD, Intel, Qualcomm, etc before making something that is really only useful at Google.
tipseason 4y ago
Although it has both advantages, disadvantages and it's still being in an experiment phase, it's definitely a refreshing feeling in terms of syntax compared to C++. Tried with various different examples with different basic usage and wrote a detailed guide. If you want to get a quick feeling of how it looks like in terms of syntax, check this beginner tutorial. https://tipseason.com/carbon-language-tutorial-syntax/ https://tipseason.com/carbon-language-tutorial-syntax/
miohtama 4y ago
It’s clear that the value promise of Carbon is to make it attractive to port existing C++ applications to it. But how this is accomplished, article does not go into detail in this. Is there going to be ABI compatibility with C++? What are the features that make Carbon a better porting target than Rust?
- timbit42 4y ago
  Rust is closer to the the type of languages we need to move to but Carbon makes it easier to port away from existing C++ software. If it's a new project, use Rust if you can. Use Carbon if you need to deal with C++. Rust can interoperate with C++ but with more difficulty.
- kirbyfan64sos 4y ago
  The official webisite (https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang) goes into better detail, but the gist is that you can basically #include C++ libraries and use their APIs as-is, without needing to resort to unsafe blocks or having to write more idiomatic wrappers.
  - miohtama 4y ago
    Does this mean that Carbon needs to include a whole C++ compiler as a part of Carbon compiler?
    - pitaj 4y ago
      Carbon uses LLVM as a backend, so I imagine they just call into Clang for such things.
- flumpcakes 4y ago
  There is ABI compatibility insofar that Carbon will be able to integrate C++ at the AST level within the compiler. This is quite smart as you are basically getting ABI compatibility for free. Assuming you have the source code to the C++. I'm not sure how it will work with dynamic or proprietary libraries, but as I understand it that is already a technically unsolved ABI problem with C++.
xenonite 4y ago
Previous discussion: https://news.ycombinator.com/item?id=32151609 https://news.ycombinator.com/item?id=32151609
melling 4y ago
I’m a big fan of ‘var’ and ‘let’ in Swift. Easier to identify mutable vs immutable variables. I believe Carbon uses the same convention? https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang Helps with quick auto-completion, and someday when I get to dictate code, fewer mistakes.
- nazgulsenpai 4y ago
  Nim also uses 'var' and 'let' for mutability. I like it as well.
  - tekknik 4y ago
    knowing neither of these languages i’d rather it be labeled something more clear as neither one of those screams immutable to me. the immutable variant should use the ‘const’ keyword instead.
    - KptMarchewa 4y ago
      I hope they won't use const. The meaning of it is extremely overloaded in C++.
    - donarb 4y ago
      Const variables are traditionally initialized at compiled time. In Swift, let may be initialized at runtime and then becomes immutable.
      - tekknik 4y ago
        that’s just a choice by the language designer. nothing prohibits initialization at runtime.
    - ladberg 4y ago
      To me `var` by definition means mutable and `let` sounds like you're laying out a constant in a proof, so I'd say both are pretty clear.
hbossy 4y ago
var r : i32; How is this any better than int32_t r; ? all I see is additional, unnecessary keyword to type.
- melling 4y ago
  You type about the same number of characters. Now imagine you wanted to declare the value to be immutable.
  - TinkersW 4y ago
    Its 5 extra characters actually.. because any sensible C++ project has i32 etc defined. The type omission version isn't very useful, as this type of code is difficult to read later. Generally end up regretting using auto, and end up converting it to the actual type, except with iterators or nasty templates.
    - deadbeeves 4y ago
      That hasn't been my experience, personally. In fact, sometimes I wish decltype was easier to use, to declare type dependencies.
  - hbossy 4y ago
    That's only true because they used build-in int type. Why would I prefer to use: var inst : MyClass; over MyClass inst;
- norman784 4y ago
  I think by using `var` keyword you have the potential to inherit the type without changing too much the syntax, in rust you could omit the type if the compiler can inherit the type, that saves you a lot of typing in the future, but you could argue that it makes harder to read the source code without any tool.
  - tialaramex 4y ago
    The word you wanted was "infer" not "inherit" For example "if the compiler can inherit the type" should read "if the compiler can infer the type".
sylware 4y ago
If you cannot write a naive "carbon" compiler as a small team or even an normally skilled individual in a reasonable amount of time and effort, same abomination than c++ syntax, next.
oDot 4y ago
Looks like there's no need to wait for Unreal Verse anymore
udbhavs 4y ago
I've been seeing a lot of references to this across youtube, reddit etc for a new experimental language. Is google putting their full weight behind this like Go or is the virality just incidental?
- tialaramex 4y ago
  Lots of people are interested in replacing C++. They disagree about what the replacement should be, to some extent because what they think is wrong with C++ can be quite different. This is a team of people with serious C++ backgrounds, who explicitly are interested in this as a successor to C++. Some of these are people who worked on P2137 which is the "Goals and priorities" paper that the committee explicitly rejected for C++ 20, so they know what they think C++ should be, and they know WG21 doesn't want that, so if they do want it they're going to need a separate vehicle to get there. Also they're far from finished, so there's the attraction that Carbon could be whatever it is you want, while something like Rust has decided what it is.
pipeline_peak 4y ago
> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?
- htrp 4y ago
  so basically Google C
- rvnx 4y ago
  We're just gonna add a 6th standard to end all standards.
- brightball 4y ago
  I haven't used Rust much, but based on everything I've read it seems like if you need a better alternative to C or C++...Rust is pretty much the answer. Is that not accurate?
  - baobob 4y ago
    This comment and parent comment don't appear to have read the article. It's specifically targetting C++ compatibility, that means compatible threading model, memory model, ABI, type system, ... Rust has none of these. For every line of Rust code in the world, there are likely 10e3 - 100e3 lines of C++. You can either label it all "legacy code" and pretend your employer has the budget or time to rewrite it all, or you can find something in between writing new "legacy code", or throwing away your (for a company like Google) absolutely huge investment. FWIW projects that build for interoperability have a much higher chance of long term success than those that don't. This is true for everything in software, not just programming languages. For this reason alone you can't easily compare Carbon and Rust. Carbon sounds something a little closer to Vala (C compatibility) than anything like Rust
    - pipeline_peak 4y ago
      You didn't appear to read my comment, I'm talking about compatibility with Rust and all these other look alike languages. Also your Vala comparison would imply this language compiles to C++.
robmccoll 4y ago
I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is expressive, performant, and small while still general purpose is quite a challenge.
- dzonga 4y ago
  to me that's the greatest benefit of C++ and hence why it's so successful. it's kitchen sink language. choose what features you want. choose your own style. you wanna do OOP | DOP suit yourself. that versatility is why C++ is unmatched in terms of where it's deployed.
  - robmccoll 4y ago
    The more recent editions of C++ do seem to support this idea. Things are at least better than when the trade off was taking advantage of C++ features (and more C++ like) or performance (and more C-like C++). The problem that there are only a handful of people who could realistically claim to be experts in C++ has gotten worse over time as the language has expanded though. It's a language where you potentially have to train new C++ programmers that join your team in how your team uses C++.
  - est31 4y ago
    That's great if there is one developer working on each component of the software. The moment you have people trying to do cross-component changes, or developing someone else's component, they don't just have to learn how the code works on a domain level, but also the features of the language the code is using.
  - cute_boi 4y ago
    Well upto certain limits versatility is important. But, being too versatile also brings more complexity and it makes language confusing. I read more code than I write, so this versatily is not good for people like me.
deleted 4y ago
[deleted]
quietbritishjim 4y ago
Does anyone know what the move / copy semantics are in Carbon? I can't figure it out from the docs (admittedly I have not looked hard at all). I would say the number one weakness of C++ is its model of copy by default and often by surprise. For example: f(std::move(x)) will copy x if x is const or f takes its value by const ref - rather than a compiler error as you might reasonably expect (if you don't know the C++ reference model inside out). In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. I personally think that is all more useful than the borrow checker. If Carbon has the same bizarre move/copy rules as C++ then the effort is wasted IMO.
- yakubin 4y ago
  > In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. I personally think that is all more useful than the borrow checker. Without the borrow checker, this "move-by-default, move is memcpy" semantics would break all hell loose. Dangling pointers/references would be everywhere. I like this part of Rust, but I'm not sure if it can work in a non-GC, no-borrow-checker language.
  - quietbritishjim 4y ago
    You would need to add the rule that you can't move from a variable in only one branch of an if statement or from any sort of loop. Like a really primitive compile time borrow checker. It seems to me that would be enough, but maybe I haven't thought it through properly, or maybe you'd end up having to copy a lot more often than you want to (or use optional half the time, which might defeat the point a bit).
  - jcranmer 4y ago
    You don't need a full-on borrow-checker to make move-by-default safe. If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.
russtrotter 4y ago
The first half of the article started to feel like the XKCD "15th standard" meme, but at the end, the more nuanced point was presented: If you're already using Rust, stick with Rust. Carbon is positioned as successor language for those with large C++ codebases difficult to convert to Rust. Interesting tact, and at face value that concession might undermine adoption given that Rust has a big head start and not hinged to a corp with a well-earned reputation for killing projects.
ho_schi 4y ago
> Frustrated by the slow evolution I think already the very first sentence is already wrong. 1998 ISO/IEC 14882:1998 C++98 2003 ISO/IEC 14882:2003 C++03 2011 ISO/IEC 14882:2011 C++11 2014 ISO/IEC 14882:2014 C++14 2017 ISO/IEC 14882:2017 C++17 2020 ISO/IEC 14882:2020 C++20 Where C++11 and C++20 are huge major upgrades.
- zaphar 4y ago
  Major upgrades that are fully backward compatible and therefore leave some significant performance and safety bugs untouched. What they mean by "slow evolution" is the increasing rigidity of core data structures and resistance to introducing replacements caused by the backwards compatibility promise. Adding new features is easier than changing existing ones. This is both a strength and a weakness of C++. It's a very old language and it has been keeping that backwards compatibility promise for a very long time. The result is that certain portions of the language are effectively unchangeable as a result. This is the key thing that Rust's editions are trying avoid.
- tialaramex 4y ago
  The ability to ship new slightly incompatible versions of your "International Standard" every three years doesn't mean you're evolving quickly. > Where C++11 and C++20 are huge major upgrades. They seem significant by the standards of C++ but they're rather less impressive in the bigger picture.
- KptMarchewa 4y ago
  Those standards are mostly additive, while Google wants to fix some fundamental issues with the language.
- stonemetal12 4y ago
  Looks fairly slow to me, C# is already on V10. C# isn't nearly as old, and has had much larger features added.
  - deleted 4y ago
    [deleted]
jeffbee 4y ago
Is there already a substantial amount of this in Google’s repos? It would be in character for them to reveal this after it’s already well-established internally.
- jcranmer 4y ago
  There's enough gaps in the specification (move/copy situation in particular) that would make me hesitant to use this for any production code. Given that the code seems to date from WG21's rejection of the Google-led "we want to add a hard ABI break in C++23" proposal, the project is barely 2 years from literal first commit, which is likely too short to attract any substantial internal usage.
  - gpderetta 4y ago
    I think this is supposed to be the pre-alpha-broken-preview-dont-use-in-prod stage. So don't use it in prod :)
williamstein 4y ago
Zig is to C as Carbon is to C++? The interop with existing C++ code, and ability to compile and understand existing code seems very similar.
drawkbox 4y ago
The example to me looks like C++ is still nicer, I don't get the hate on C++ but then again most of the native work I do is gamedev. The benefit that C++ and Carbon can run together is a nice feature. It is like Objective-C++ (using ObjC + C++ together) or Swift/ObjC that worked well in gamedev as well when you needed to wire in a C/C++ game engine into iOS. For Android the NDK. I think any C++ replacement has to be compatible with C++ but at that point isn't C++ still the root? C++ will never go away and it is actually a great language that is powerful. Then again I have spent lots of time in gamedev where that matters and most libs are going to be C/C++ for the foreseeable future. Just learn C++. You'll probably need to learn C++ to understand integrations with Carbon anyways. Carbon seems like yet another language you'll have to learn that is built on and tries to replace C++. Fun fact: Fun fact: Objective-C was made in 1984, one year before C++ (1985).
- chrsig 4y ago
  I work on a project that is a c & c++ codebase where there isn't really a great reason for it being in those languages vs a language "with a runtime" the hate is pretty simple: - compile times - vague compiler errors - template syntax is incredibly hard to read, especially when using techniques like sfinae, or trying to write functional interfaces - really bad names for idioms (raii, sfinae, pimpl) - really bad names for standard library types & functions - truly arrogant community (notice how the boost website doesn't advertise that it's the easiest to use library -- it's the "most expertly designed") - class member function declaration is out of control (`virtual const foo bar(const baz& x) const override`) - defaults are unsafe (mutable by default) - package management is a nightmare (i've only used conan, which is starting to mature, but still has a limited selection of packages, and seems to constantly break how they do things...because package building for an ecosystem as wide and unstructured as c++ is an intractable problem) - cmake is the worst dsl ever. the program itself is fine, but the dsl is the worst. - footguns everywhere (auto vs auto&...but auto* exists, and isn't necessary) - N different ways of initializing - it's incredibly hard to teach - inconsistencies w/ C (brace initialization w/ named fields) - incredibly subtle things can have a huge impact (class member variable declaration order) - no standard way to document classes & functions there are still certainly use cases where it's worth using, but the hate is pretty straightforward to me: it's just more hassle than it's worth most of the time. and there is some inner language struggling to get out that's probably nice to use. There are some nice things about it: notably static destruction. and yes, some of those are more ecosystem based / my own opinions / not necessarily "the language" -- and there are reasons for why many of the warts are the way they are (backwards compatibility, control over construction order). it's still a giant pain in my ass.
squarefoot 4y ago
Speaking not from direct experience, having barely touched C++ in the past and never touched D yet, but I've read many paint it as the natural successor, so why not D?
- timbit42 4y ago
  Is D safe like Rust? I don't believe it is. I've written a little D and I like it but we need safe languages. The industry ignored the safety of Pascal, Modula-2, and Ada back in the 1970's and chose C because it was slightly faster. Now we're getting hacked left, right and center and have a huge base of C and C++. Sigh.
- olodus 4y ago
  Yeah I don't really understand that either. I have never written D myself but everyone I've looked at the language it has seemed to have sensible solutions to things and I would much rather write that than C++. I guess it hasn't as good interoperability with existing C++ as Carbon is aiming for (I don't think, could be wrong) and wouldn't give Google as much control of it as it probably will have over Carbon.
- effingwewt 4y ago
  I love C++, being old school, and would love a decent successor but I'd never again touch anything with the google death-stamp. How long before they pull the rug out, or do any of their other dirty shenanigans?
- iamcreasy 4y ago
  I've heard Jonathan Blow say D is still too much like C++ in one of the initial video on Jai.
DiabloD3 4y ago
I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I know of is basically a 100% conversion rate. Nobody at Google will use Carbon, nobody outside of Google will use Carbon. It's going to be worse than the Swift implosion.
- quietbritishjim 4y ago
  > Why try to compete with Rust while not really being a better Rust? The linked article explains this: classes defined in C++ can be used in Carbon and vice-versa. It even suggests you stick to Rust if that's not what you need. Edit: Oops, I assumed that the "linked article" was the github page[1] for Carbon, which is a lot more useful. [1] https://github.com/carbon-language/carbon-lang#why-build-carbon https://github.com/carbon-language/carbon-lang#why-build-car...
  - DiabloD3 4y ago
    I guess the README really does answer my question: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."
- KptMarchewa 4y ago
  They aren't trying to solve ownership problem as Rust does.
- sgjohnson 4y ago
  > Swift implosion What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression
Terretta 4y ago
How to make your replacement for a C language Google-able: name it after an API for a C language: Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Compare also keywords or key terms: Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need to check and recheck the code for each instantiation. Another much needed feature lacking in C++ is memory safety. Memory access bugs are one of the largest culprits of security exploits. Carbon designers will look for ways to better track uninitialized states, design APIs and idioms that support dynamic bounds checks, and build a comprehensive default debug build mode. Over time, the designers plan to build a safe Carbon subset. Versus... Carbon libraries are extensively cleaned up, modernized and better "protected". While the Mac OS was filled with APIs that shared memory to pass data, under Carbon all such access was re-implemented using accessor subroutines on opaque data types. This allowed Carbon to support true multitasking and memory protection, features Mac developers had been requesting for a decade. https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API) Go Get 'Em!
- deleted 4y ago
  [deleted]
- KptMarchewa 4y ago
  Carbon API is so old that this pretty much isn't issue. You have to google explicitely for "Carbon API" for it to show up. Whether even now, "carbon programming" or "carbon code" give results for Carbon language - and some other non-c++ libs named Carbon. Even "carbon" by itself gives me some Carbon language links.
  - tgv 4y ago
    I suppose you’re using google as a search engine?
  - scotty79 4y ago
    Don't forget they named language go, while language named Go! already existed. They just don't care. https://en.m.wikipedia.org/wiki/Go!_(programming_language) https://en.m.wikipedia.org/wiki/Go!_(programming_language)
cute_boi 4y ago
"The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux" I thought Linux was C only and Linus is actively hostile against cpp for some good reasons.
- qorrect 4y ago
  > I thought Linux was C only It won't be for long (Rust) https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linus-torvalds-predicts/ https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linu... . But I don't expect C++ to be added.
  - cesarb 4y ago
    > > I thought Linux was C only > It won't be for long (Rust) To be pedantic, it already isn't; a small but very important part of Linux is written in assembly (it used to be more, but most of it was ported to C; what's left is a small core which simply cannot be expressed correctly in C).
  - ActorNightly 4y ago
    Still a maybe, and they certainly won't be rewriting any core part of the linux in Rust. While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.
    - tialaramex 4y ago
      > Its the same reason why C++ hasn't been adopted. Among the reasons C++ hasn't been adopted for Linux: * Nobody actually did the hard work. The Rust for Linux people have spent a lot of time actually making this possible. C++ proponents tend to just drive past "Ha, you should use C++" which they presumably think makes them seem clever but it doesn't. * C++ doesn't have a coherent "freestanding" subset. In theory (and according to the ISO document) there's freestanding C++ but in practice you quickly find you need lots of custom runtime stuff, it's not really part of the C++ standard at all. * Linus is trying not to be an asshole and that's not going to be helped by introducing a C++ culture where you'll routinely see sentiments like "This has a Code of Conduct so it's for fucking snowflakes". * C++ loves implicit allocation and Linus hates implicit allocation, especially infallible allocation. Now, you could sort of fix this if you rewrote a lot of stuff, and indeed in the Rust for Linux implementation of alloc (Rust's allocation library) there are a lot of places where it does fallible allocation and doesn't offer implicit allocation. The example of the latter which won't affect most kernel programmers but I think is easiest for a typical programmer to understand is this: In C++ or Rust, if I have a string called adjective (maybe it's "Fast") and a string called noun (maybe "Cheese", and I write phrase = adjective + noun; then we're going to get the resulting word from concatenating the two strings ("FastCheese"), right? Is this abuse of the + operator? Maybe. But it works. In Rust for Linux that won't compile. Because it's an implied, infallible allocation. To put that concatenated string somewhere there's an allocation, which could fail, and how could the + operator "fail" ? Where does the error go if this happens?
tony 4y ago
How does carbon have any intersection with Google Chrome / Chromium development? Some earlier posts: - https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... - https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html https://security.googleblog.com/2021/09/an-update-on-memory-... Would carbon be a variation of "making C++ safer" mentioned in that blog post?
jdmg94 4y ago
Yet another technology Google will shove down our throats
bbarn 4y ago
Ugh, It may be superior in every way (I haven't had time to read up on how or why yet) but the name? Has no one at Google ever developed in the Apple ecosystem? I know it's been 10 years but still.. It's not as bad as Microsoft though, with the word "Unity" - both a game development platform and an IOC container. Had loads of fun googling help for the IOC container when 90% of the results were about the game dev platform - also in C#.
- runevault 4y ago
  Microsoft doesn't own the Unity engine, even though it uses the MS tech stack heavily. The IOC stuff though you aren't wrong on.
  - sprkwd 4y ago
    Not yet they don’t.
npalli 4y ago
Seven years ago someone at Google estimated that there was 2 Billion lines of code in production to support Google Services [1]. Given this was seven years ago the number is probably much higher now and a large chunk of it is C++. Clearly any replacement language for C++ has to seamlessly (as primary design goal at least) consume and update this gigantic C++ code base. Nobody is rewriting all of that from scratch. That pretty much rules out Rust, Golang and various other languages which provide a thin "extern C function" level compatibility at best. Would be interesting to see how the language progresses. [1]. https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/ https://www.wired.com/2015/09/google-2-billion-lines-codeand...
- hnov 4y ago
  Exactly, Rust has been around for a while and it hasn't reached parity in terms of LoC with C and C++ in Gecko's codebase, presumably because it's impossible to rewrite individual units unless the API is impossibly narrow. This new language will be more like different JVM langs in terms of interop.
- jsharf 4y ago
  You don't need to rewrite existing code. Just develop new code in it.
rajman187 4y ago
While I have not had time to check this out, more generally whenever I read “Google launches…” I wonder how long until it makes it into the ever-growing graveyard? [1] https://killedbygoogle.com/ https://killedbygoogle.com/ [2] https://gcemetery.co/ https://gcemetery.co/
- jsnell 4y ago
  This is an experimental project, being very clearly pitched as such, and with the documentation being really clear about how if you can use any other language you should. They're bending over backwards to make the expectations clear. It is being developed in the open, targets a goverance model of an open foundation not controlled by any company, and has a goal that no more than half the contributors to the language should be from any one company. It's also a programming language whose compiler you'd run on your local machine, not a networked service that can actually be shut down. Out of all the projects where you could trot out this tired "killed by google" shit, this is literally the worst one. What is your thought process here? "I don't know anything about the subject, but let me repeat a lame joke that people will surely find hilarious despite it being the thousandth time it gets posted to HN this year. Surely it will play to the crowd."
  - trasz 4y ago
    >not controlled by any company, and has a goal that no more than half the contributors to the language should be from any one company Not controlled by Google in that Google literally owns at most half of it?
    - jsnell 4y ago
      No, those are two separate things which is why I listed them separately. There is the question of the governance / ownership model is (independent foundation), and the question of having a broad base of contributors to the design / implementation. What, exactly, would they need to do to satisfy you?
      - 4y ago
NonNefarious 4y ago
[flagged]
kova12 4y ago
Okay... Does this new hotness support exceptions?
dqpb 4y ago
So, is Carbon supposed to replace Go as well?
- timbit42 4y ago
  No. Different targets.
jedberg 4y ago
Why does Google keep choosing un-googleable programming language names (go and now carbon)?
- chrsig 4y ago
  How else are they going to enable pedant conversations about how "the language name is carbon not carbon-lang"?
yc-kraln 4y ago
Carbon, Go, Sawzal, Dart. Is this a retention activity, or do they honestly think that creating their own programming languages and tooling will help them meet their goals?
DethNinja 4y ago
How fast are the compile speeds compared to C++? If Carbon can convert existing C++ code, still be human readable and have way faster compile speeds, then yeah it can kill C++. I think I’ll wait couple more years before trying though.
- timbit42 4y ago
  Very slow right now but it's still in beta so it is not at all indicative of the compilation speed it will ultimately achieve.
Nimitz14 4y ago
Why are new languages always putting the type on the right :(
- timbit42 4y ago
  Like Pascal, Modula-2 and Oberon I guess.
js4ever 4y ago
Like everything from Google I'm too worried that it will be deprecated or evolution to be incompatible with previous versions to touch it. Google might have the human power to rewrite their codebase every 6 months... But I don't. I need something stable.
pkphilip 4y ago
Why not develop Zig to include OOP?
theplumber 4y ago
This is doomed to fail b/c it uses semicolons. Why would you use semicolons in 2022?
cudgy 4y ago
Looks like Swift.
tpoacher 4y ago
groundhog () { s/rust/carbon/g ; }

168 points by isaacfrond 4y ago

in9 4y ago

wasn't go supposed to be a replacement for C++?

timbit42 4y ago
No. It's more like a fast Python.
vultour 4y ago
I don't think one should consider any language with a garbage collector a replacement for C++. I love Go but in my opinion it serves a different purpose than C++ or Rust.

petre 4y ago

There's already a successor to C++. It's called D.

timbit42 4y ago
How does D's safety compare to Rust and Carbon?

debug-desperado 4y ago

Not a C++ programmer, but I'd like to ask: Are Carbon's goals for interop here sufficient for most libraries and frameworks, or will bridge code be required in most cases? I see this about exceptions, for instance: "Carbon may not provide seamless interoperability support for C++ exceptions. For example, translating C++ exceptions to or from Carbon errors might require annotations or bridge code, and those translations may have some performance overhead or lose information. Furthermore, if Carbon code calls a C++ function without suitable annotations or bridging, and that function exits with an exception, the program might terminate." https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/interoperability/philosophy_and_goals.md#non-goals https://github.com/carbon-language/carbon-lang/blob/trunk/do...

sseth 4y ago
I am guessing that this is less of a concern for Google. Per Google's C++ style guide : "We do not use C++ exceptions." So they are already not using that feature in their C++ code today. https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
- debug-desperado 4y ago
  That’s what I was getting at. I hope they get some real feedback from Nvidia, AMD, Intel, Qualcomm, etc before making something that is really only useful at Google.

tipseason 4y ago

Although it has both advantages, disadvantages and it's still being in an experiment phase, it's definitely a refreshing feeling in terms of syntax compared to C++. Tried with various different examples with different basic usage and wrote a detailed guide. If you want to get a quick feeling of how it looks like in terms of syntax, check this beginner tutorial. https://tipseason.com/carbon-language-tutorial-syntax/ https://tipseason.com/carbon-language-tutorial-syntax/

miohtama 4y ago

It’s clear that the value promise of Carbon is to make it attractive to port existing C++ applications to it. But how this is accomplished, article does not go into detail in this. Is there going to be ABI compatibility with C++? What are the features that make Carbon a better porting target than Rust?

timbit42 4y ago
Rust is closer to the the type of languages we need to move to but Carbon makes it easier to port away from existing C++ software. If it's a new project, use Rust if you can. Use Carbon if you need to deal with C++. Rust can interoperate with C++ but with more difficulty.
kirbyfan64sos 4y ago
The official webisite (https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang) goes into better detail, but the gist is that you can basically #include C++ libraries and use their APIs as-is, without needing to resort to unsafe blocks or having to write more idiomatic wrappers.
- miohtama 4y ago
  Does this mean that Carbon needs to include a whole C++ compiler as a part of Carbon compiler?
  - pitaj 4y ago
    Carbon uses LLVM as a backend, so I imagine they just call into Clang for such things.
flumpcakes 4y ago
There is ABI compatibility insofar that Carbon will be able to integrate C++ at the AST level within the compiler. This is quite smart as you are basically getting ABI compatibility for free. Assuming you have the source code to the C++. I'm not sure how it will work with dynamic or proprietary libraries, but as I understand it that is already a technically unsolved ABI problem with C++.

xenonite 4y ago

Previous discussion: https://news.ycombinator.com/item?id=32151609 https://news.ycombinator.com/item?id=32151609

melling 4y ago

I’m a big fan of ‘var’ and ‘let’ in Swift. Easier to identify mutable vs immutable variables. I believe Carbon uses the same convention? https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang Helps with quick auto-completion, and someday when I get to dictate code, fewer mistakes.

nazgulsenpai 4y ago
Nim also uses 'var' and 'let' for mutability. I like it as well.
- tekknik 4y ago
  knowing neither of these languages i’d rather it be labeled something more clear as neither one of those screams immutable to me. the immutable variant should use the ‘const’ keyword instead.
  - KptMarchewa 4y ago
    I hope they won't use const. The meaning of it is extremely overloaded in C++.
  - donarb 4y ago
    Const variables are traditionally initialized at compiled time. In Swift, let may be initialized at runtime and then becomes immutable.
    - tekknik 4y ago
      that’s just a choice by the language designer. nothing prohibits initialization at runtime.
  - ladberg 4y ago
    To me `var` by definition means mutable and `let` sounds like you're laying out a constant in a proof, so I'd say both are pretty clear.

hbossy 4y ago

var r : i32; How is this any better than int32_t r; ? all I see is additional, unnecessary keyword to type.

melling 4y ago
You type about the same number of characters. Now imagine you wanted to declare the value to be immutable.
- TinkersW 4y ago
  Its 5 extra characters actually.. because any sensible C++ project has i32 etc defined. The type omission version isn't very useful, as this type of code is difficult to read later. Generally end up regretting using auto, and end up converting it to the actual type, except with iterators or nasty templates.
  - deadbeeves 4y ago
    That hasn't been my experience, personally. In fact, sometimes I wish decltype was easier to use, to declare type dependencies.
- hbossy 4y ago
  That's only true because they used build-in int type. Why would I prefer to use: var inst : MyClass; over MyClass inst;
norman784 4y ago
I think by using `var` keyword you have the potential to inherit the type without changing too much the syntax, in rust you could omit the type if the compiler can inherit the type, that saves you a lot of typing in the future, but you could argue that it makes harder to read the source code without any tool.
- tialaramex 4y ago
  The word you wanted was "infer" not "inherit" For example "if the compiler can inherit the type" should read "if the compiler can infer the type".

sylware 4y ago

If you cannot write a naive "carbon" compiler as a small team or even an normally skilled individual in a reasonable amount of time and effort, same abomination than c++ syntax, next.

oDot 4y ago

Looks like there's no need to wait for Unreal Verse anymore

udbhavs 4y ago

I've been seeing a lot of references to this across youtube, reddit etc for a new experimental language. Is google putting their full weight behind this like Go or is the virality just incidental?

tialaramex 4y ago
Lots of people are interested in replacing C++. They disagree about what the replacement should be, to some extent because what they think is wrong with C++ can be quite different. This is a team of people with serious C++ backgrounds, who explicitly are interested in this as a successor to C++. Some of these are people who worked on P2137 which is the "Goals and priorities" paper that the committee explicitly rejected for C++ 20, so they know what they think C++ should be, and they know WG21 doesn't want that, so if they do want it they're going to need a separate vehicle to get there. Also they're far from finished, so there's the attraction that Carbon could be whatever it is you want, while something like Rust has decided what it is.

pipeline_peak 4y ago

> Complains C++ evolution is too slow due to enforced standardizations by committee. > Introduces yet another non standardized, corporately backed Rust look-alike language. What's gonna happen when we have 5 of these things crawling around, are they going to be compatible with each other?

htrp 4y ago
so basically Google C
rvnx 4y ago
We're just gonna add a 6th standard to end all standards.
brightball 4y ago
I haven't used Rust much, but based on everything I've read it seems like if you need a better alternative to C or C++...Rust is pretty much the answer. Is that not accurate?
- baobob 4y ago
  This comment and parent comment don't appear to have read the article. It's specifically targetting C++ compatibility, that means compatible threading model, memory model, ABI, type system, ... Rust has none of these. For every line of Rust code in the world, there are likely 10e3 - 100e3 lines of C++. You can either label it all "legacy code" and pretend your employer has the budget or time to rewrite it all, or you can find something in between writing new "legacy code", or throwing away your (for a company like Google) absolutely huge investment. FWIW projects that build for interoperability have a much higher chance of long term success than those that don't. This is true for everything in software, not just programming languages. For this reason alone you can't easily compare Carbon and Rust. Carbon sounds something a little closer to Vala (C compatibility) than anything like Rust
  - pipeline_peak 4y ago
    You didn't appear to read my comment, I'm talking about compatibility with Rust and all these other look alike languages. Also your Vala comparison would imply this language compiles to C++.

robmccoll 4y ago

I'm probably just biased, but to me the problem with modern C++ is its complexity. The mental model of the language, its syntax, and the amount of history / number of interfaces a programmer needs to be familiar with to be productive are all too large. Rust isn't any more complex, but it's not radically simpler either. Carbon doesn't look like it solves this problem. It would seem that creating a language that is expressive, performant, and small while still general purpose is quite a challenge.

dzonga 4y ago
to me that's the greatest benefit of C++ and hence why it's so successful. it's kitchen sink language. choose what features you want. choose your own style. you wanna do OOP | DOP suit yourself. that versatility is why C++ is unmatched in terms of where it's deployed.
- robmccoll 4y ago
  The more recent editions of C++ do seem to support this idea. Things are at least better than when the trade off was taking advantage of C++ features (and more C++ like) or performance (and more C-like C++). The problem that there are only a handful of people who could realistically claim to be experts in C++ has gotten worse over time as the language has expanded though. It's a language where you potentially have to train new C++ programmers that join your team in how your team uses C++.
- est31 4y ago
  That's great if there is one developer working on each component of the software. The moment you have people trying to do cross-component changes, or developing someone else's component, they don't just have to learn how the code works on a domain level, but also the features of the language the code is using.
- cute_boi 4y ago
  Well upto certain limits versatility is important. But, being too versatile also brings more complexity and it makes language confusing. I read more code than I write, so this versatily is not good for people like me.

deleted 4y ago

[deleted]

quietbritishjim 4y ago

Does anyone know what the move / copy semantics are in Carbon? I can't figure it out from the docs (admittedly I have not looked hard at all). I would say the number one weakness of C++ is its model of copy by default and often by surprise. For example: f(std::move(x)) will copy x if x is const or f takes its value by const ref - rather than a compiler error as you might reasonably expect (if you don't know the C++ reference model inside out). In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. I personally think that is all more useful than the borrow checker. If Carbon has the same bizarre move/copy rules as C++ then the effort is wasted IMO.

yakubin 4y ago
> In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. I personally think that is all more useful than the borrow checker. Without the borrow checker, this "move-by-default, move is memcpy" semantics would break all hell loose. Dangling pointers/references would be everywhere. I like this part of Rust, but I'm not sure if it can work in a non-GC, no-borrow-checker language.
- quietbritishjim 4y ago
  You would need to add the rule that you can't move from a variable in only one branch of an if statement or from any sort of loop. Like a really primitive compile time borrow checker. It seems to me that would be enough, but maybe I haven't thought it through properly, or maybe you'd end up having to copy a lot more often than you want to (or use optional half the time, which might defeat the point a bit).
- jcranmer 4y ago
  You don't need a full-on borrow-checker to make move-by-default safe. If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.

russtrotter 4y ago

The first half of the article started to feel like the XKCD "15th standard" meme, but at the end, the more nuanced point was presented: If you're already using Rust, stick with Rust. Carbon is positioned as successor language for those with large C++ codebases difficult to convert to Rust. Interesting tact, and at face value that concession might undermine adoption given that Rust has a big head start and not hinged to a corp with a well-earned reputation for killing projects.

ho_schi 4y ago

> Frustrated by the slow evolution I think already the very first sentence is already wrong. 1998 ISO/IEC 14882:1998 C++98 2003 ISO/IEC 14882:2003 C++03 2011 ISO/IEC 14882:2011 C++11 2014 ISO/IEC 14882:2014 C++14 2017 ISO/IEC 14882:2017 C++17 2020 ISO/IEC 14882:2020 C++20 Where C++11 and C++20 are huge major upgrades.

zaphar 4y ago
Major upgrades that are fully backward compatible and therefore leave some significant performance and safety bugs untouched. What they mean by "slow evolution" is the increasing rigidity of core data structures and resistance to introducing replacements caused by the backwards compatibility promise. Adding new features is easier than changing existing ones. This is both a strength and a weakness of C++. It's a very old language and it has been keeping that backwards compatibility promise for a very long time. The result is that certain portions of the language are effectively unchangeable as a result. This is the key thing that Rust's editions are trying avoid.
tialaramex 4y ago
The ability to ship new slightly incompatible versions of your "International Standard" every three years doesn't mean you're evolving quickly. > Where C++11 and C++20 are huge major upgrades. They seem significant by the standards of C++ but they're rather less impressive in the bigger picture.
KptMarchewa 4y ago
Those standards are mostly additive, while Google wants to fix some fundamental issues with the language.
stonemetal12 4y ago
Looks fairly slow to me, C# is already on V10. C# isn't nearly as old, and has had much larger features added.
- deleted 4y ago
  [deleted]

jeffbee 4y ago

Is there already a substantial amount of this in Google’s repos? It would be in character for them to reveal this after it’s already well-established internally.

jcranmer 4y ago
There's enough gaps in the specification (move/copy situation in particular) that would make me hesitant to use this for any production code. Given that the code seems to date from WG21's rejection of the Google-led "we want to add a hard ABI break in C++23" proposal, the project is barely 2 years from literal first commit, which is likely too short to attract any substantial internal usage.
- gpderetta 4y ago
  I think this is supposed to be the pre-alpha-broken-preview-dont-use-in-prod stage. So don't use it in prod :)

williamstein 4y ago

Zig is to C as Carbon is to C++? The interop with existing C++ code, and ability to compile and understand existing code seems very similar.

drawkbox 4y ago

The example to me looks like C++ is still nicer, I don't get the hate on C++ but then again most of the native work I do is gamedev. The benefit that C++ and Carbon can run together is a nice feature. It is like Objective-C++ (using ObjC + C++ together) or Swift/ObjC that worked well in gamedev as well when you needed to wire in a C/C++ game engine into iOS. For Android the NDK. I think any C++ replacement has to be compatible with C++ but at that point isn't C++ still the root? C++ will never go away and it is actually a great language that is powerful. Then again I have spent lots of time in gamedev where that matters and most libs are going to be C/C++ for the foreseeable future. Just learn C++. You'll probably need to learn C++ to understand integrations with Carbon anyways. Carbon seems like yet another language you'll have to learn that is built on and tries to replace C++. Fun fact: Fun fact: Objective-C was made in 1984, one year before C++ (1985).

chrsig 4y ago
I work on a project that is a c & c++ codebase where there isn't really a great reason for it being in those languages vs a language "with a runtime" the hate is pretty simple: - compile times - vague compiler errors - template syntax is incredibly hard to read, especially when using techniques like sfinae, or trying to write functional interfaces - really bad names for idioms (raii, sfinae, pimpl) - really bad names for standard library types & functions - truly arrogant community (notice how the boost website doesn't advertise that it's the easiest to use library -- it's the "most expertly designed") - class member function declaration is out of control (`virtual const foo bar(const baz& x) const override`) - defaults are unsafe (mutable by default) - package management is a nightmare (i've only used conan, which is starting to mature, but still has a limited selection of packages, and seems to constantly break how they do things...because package building for an ecosystem as wide and unstructured as c++ is an intractable problem) - cmake is the worst dsl ever. the program itself is fine, but the dsl is the worst. - footguns everywhere (auto vs auto&...but auto* exists, and isn't necessary) - N different ways of initializing - it's incredibly hard to teach - inconsistencies w/ C (brace initialization w/ named fields) - incredibly subtle things can have a huge impact (class member variable declaration order) - no standard way to document classes & functions there are still certainly use cases where it's worth using, but the hate is pretty straightforward to me: it's just more hassle than it's worth most of the time. and there is some inner language struggling to get out that's probably nice to use. There are some nice things about it: notably static destruction. and yes, some of those are more ecosystem based / my own opinions / not necessarily "the language" -- and there are reasons for why many of the warts are the way they are (backwards compatibility, control over construction order). it's still a giant pain in my ass.

squarefoot 4y ago

Speaking not from direct experience, having barely touched C++ in the past and never touched D yet, but I've read many paint it as the natural successor, so why not D?

timbit42 4y ago
Is D safe like Rust? I don't believe it is. I've written a little D and I like it but we need safe languages. The industry ignored the safety of Pascal, Modula-2, and Ada back in the 1970's and chose C because it was slightly faster. Now we're getting hacked left, right and center and have a huge base of C and C++. Sigh.
olodus 4y ago
Yeah I don't really understand that either. I have never written D myself but everyone I've looked at the language it has seemed to have sensible solutions to things and I would much rather write that than C++. I guess it hasn't as good interoperability with existing C++ as Carbon is aiming for (I don't think, could be wrong) and wouldn't give Google as much control of it as it probably will have over Carbon.
effingwewt 4y ago
I love C++, being old school, and would love a decent successor but I'd never again touch anything with the google death-stamp. How long before they pull the rug out, or do any of their other dirty shenanigans?
iamcreasy 4y ago
I've heard Jonathan Blow say D is still too much like C++ in one of the initial video on Jai.

DiabloD3 4y ago

I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I know of is basically a 100% conversion rate. Nobody at Google will use Carbon, nobody outside of Google will use Carbon. It's going to be worse than the Swift implosion.

quietbritishjim 4y ago
> Why try to compete with Rust while not really being a better Rust? The linked article explains this: classes defined in C++ can be used in Carbon and vice-versa. It even suggests you stick to Rust if that's not what you need. Edit: Oops, I assumed that the "linked article" was the github page[1] for Carbon, which is a lot more useful. [1] https://github.com/carbon-language/carbon-lang#why-build-carbon https://github.com/carbon-language/carbon-lang#why-build-car...
- DiabloD3 4y ago
  I guess the README really does answer my question: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."
KptMarchewa 4y ago
They aren't trying to solve ownership problem as Rust does.
sgjohnson 4y ago
> Swift implosion What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression

Terretta 4y ago

How to make your replacement for a C language Google-able: name it after an API for a C language: Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Compare also keywords or key terms: Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need to check and recheck the code for each instantiation. Another much needed feature lacking in C++ is memory safety. Memory access bugs are one of the largest culprits of security exploits. Carbon designers will look for ways to better track uninitialized states, design APIs and idioms that support dynamic bounds checks, and build a comprehensive default debug build mode. Over time, the designers plan to build a safe Carbon subset. Versus... Carbon libraries are extensively cleaned up, modernized and better "protected". While the Mac OS was filled with APIs that shared memory to pass data, under Carbon all such access was re-implemented using accessor subroutines on opaque data types. This allowed Carbon to support true multitasking and memory protection, features Mac developers had been requesting for a decade. https://en.wikipedia.org/wiki/Carbon_(API) https://en.wikipedia.org/wiki/Carbon_(API) Go Get 'Em!

deleted 4y ago
[deleted]
KptMarchewa 4y ago
Carbon API is so old that this pretty much isn't issue. You have to google explicitely for "Carbon API" for it to show up. Whether even now, "carbon programming" or "carbon code" give results for Carbon language - and some other non-c++ libs named Carbon. Even "carbon" by itself gives me some Carbon language links.
- tgv 4y ago
  I suppose you’re using google as a search engine?
- scotty79 4y ago
  Don't forget they named language go, while language named Go! already existed. They just don't care. https://en.m.wikipedia.org/wiki/Go!_(programming_language) https://en.m.wikipedia.org/wiki/Go!_(programming_language)

cute_boi 4y ago

"The keepers of C++ prioritize backward compatibility, in order to continue to support widely-used projects such as Linux" I thought Linux was C only and Linus is actively hostile against cpp for some good reasons.

qorrect 4y ago
> I thought Linux was C only It won't be for long (Rust) https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linus-torvalds-predicts/ https://thenewstack.io/rust-in-the-linux-kernel-by-2023-linu... . But I don't expect C++ to be added.
- cesarb 4y ago
  > > I thought Linux was C only > It won't be for long (Rust) To be pedantic, it already isn't; a small but very important part of Linux is written in assembly (it used to be more, but most of it was ported to C; what's left is a small core which simply cannot be expressed correctly in C).
- ActorNightly 4y ago
  Still a maybe, and they certainly won't be rewriting any core part of the linux in Rust. While the memory safety aspects of Rust is good for security, its still an evolving language and doesn't have the same stability as C. Its the same reason why C++ hasn't been adopted.
  - tialaramex 4y ago
    > Its the same reason why C++ hasn't been adopted. Among the reasons C++ hasn't been adopted for Linux: * Nobody actually did the hard work. The Rust for Linux people have spent a lot of time actually making this possible. C++ proponents tend to just drive past "Ha, you should use C++" which they presumably think makes them seem clever but it doesn't. * C++ doesn't have a coherent "freestanding" subset. In theory (and according to the ISO document) there's freestanding C++ but in practice you quickly find you need lots of custom runtime stuff, it's not really part of the C++ standard at all. * Linus is trying not to be an asshole and that's not going to be helped by introducing a C++ culture where you'll routinely see sentiments like "This has a Code of Conduct so it's for fucking snowflakes". * C++ loves implicit allocation and Linus hates implicit allocation, especially infallible allocation. Now, you could sort of fix this if you rewrote a lot of stuff, and indeed in the Rust for Linux implementation of alloc (Rust's allocation library) there are a lot of places where it does fallible allocation and doesn't offer implicit allocation. The example of the latter which won't affect most kernel programmers but I think is easiest for a typical programmer to understand is this: In C++ or Rust, if I have a string called adjective (maybe it's "Fast") and a string called noun (maybe "Cheese", and I write phrase = adjective + noun; then we're going to get the resulting word from concatenating the two strings ("FastCheese"), right? Is this abuse of the + operator? Maybe. But it works. In Rust for Linux that won't compile. Because it's an implied, infallible allocation. To put that concatenated string somewhere there's an allocation, which could fail, and how could the + operator "fail" ? Where does the error go if this happens?

tony 4y ago

How does carbon have any intersection with Google Chrome / Chromium development? Some earlier posts: - https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rust-toolchain.md https://chromium.googlesource.com/chromium/src/+/refs/heads/... - https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html https://security.googleblog.com/2021/09/an-update-on-memory-... Would carbon be a variation of "making C++ safer" mentioned in that blog post?

jdmg94 4y ago

Yet another technology Google will shove down our throats

bbarn 4y ago

Ugh, It may be superior in every way (I haven't had time to read up on how or why yet) but the name? Has no one at Google ever developed in the Apple ecosystem? I know it's been 10 years but still.. It's not as bad as Microsoft though, with the word "Unity" - both a game development platform and an IOC container. Had loads of fun googling help for the IOC container when 90% of the results were about the game dev platform - also in C#.

runevault 4y ago
Microsoft doesn't own the Unity engine, even though it uses the MS tech stack heavily. The IOC stuff though you aren't wrong on.
- sprkwd 4y ago
  Not yet they don’t.

npalli 4y ago

Seven years ago someone at Google estimated that there was 2 Billion lines of code in production to support Google Services [1]. Given this was seven years ago the number is probably much higher now and a large chunk of it is C++. Clearly any replacement language for C++ has to seamlessly (as primary design goal at least) consume and update this gigantic C++ code base. Nobody is rewriting all of that from scratch. That pretty much rules out Rust, Golang and various other languages which provide a thin "extern C function" level compatibility at best. Would be interesting to see how the language progresses. [1]. https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/ https://www.wired.com/2015/09/google-2-billion-lines-codeand...

hnov 4y ago
Exactly, Rust has been around for a while and it hasn't reached parity in terms of LoC with C and C++ in Gecko's codebase, presumably because it's impossible to rewrite individual units unless the API is impossibly narrow. This new language will be more like different JVM langs in terms of interop.
jsharf 4y ago
You don't need to rewrite existing code. Just develop new code in it.

rajman187 4y ago

While I have not had time to check this out, more generally whenever I read “Google launches…” I wonder how long until it makes it into the ever-growing graveyard? [1] https://killedbygoogle.com/ https://killedbygoogle.com/ [2] https://gcemetery.co/ https://gcemetery.co/

jsnell 4y ago
This is an experimental project, being very clearly pitched as such, and with the documentation being really clear about how if you can use any other language you should. They're bending over backwards to make the expectations clear. It is being developed in the open, targets a goverance model of an open foundation not controlled by any company, and has a goal that no more than half the contributors to the language should be from any one company. It's also a programming language whose compiler you'd run on your local machine, not a networked service that can actually be shut down. Out of all the projects where you could trot out this tired "killed by google" shit, this is literally the worst one. What is your thought process here? "I don't know anything about the subject, but let me repeat a lame joke that people will surely find hilarious despite it being the thousandth time it gets posted to HN this year. Surely it will play to the crowd."
- trasz 4y ago
  >not controlled by any company, and has a goal that no more than half the contributors to the language should be from any one company Not controlled by Google in that Google literally owns at most half of it?
  - jsnell 4y ago
    No, those are two separate things which is why I listed them separately. There is the question of the governance / ownership model is (independent foundation), and the question of having a broad base of contributors to the design / implementation. What, exactly, would they need to do to satisfy you?
    - 4y ago

NonNefarious 4y ago

[flagged]

kova12 4y ago

Okay... Does this new hotness support exceptions?

dqpb 4y ago

So, is Carbon supposed to replace Go as well?

timbit42 4y ago
No. Different targets.

jedberg 4y ago

Why does Google keep choosing un-googleable programming language names (go and now carbon)?

chrsig 4y ago
How else are they going to enable pedant conversations about how "the language name is carbon not carbon-lang"?

yc-kraln 4y ago

Carbon, Go, Sawzal, Dart. Is this a retention activity, or do they honestly think that creating their own programming languages and tooling will help them meet their goals?

DethNinja 4y ago

How fast are the compile speeds compared to C++? If Carbon can convert existing C++ code, still be human readable and have way faster compile speeds, then yeah it can kill C++. I think I’ll wait couple more years before trying though.

timbit42 4y ago
Very slow right now but it's still in beta so it is not at all indicative of the compilation speed it will ultimately achieve.

Nimitz14 4y ago

Why are new languages always putting the type on the right :(

timbit42 4y ago
Like Pascal, Modula-2 and Oberon I guess.

js4ever 4y ago

Like everything from Google I'm too worried that it will be deprecated or evolution to be incompatible with previous versions to touch it. Google might have the human power to rewrite their codebase every 6 months... But I don't. I need something stable.

pkphilip 4y ago

Why not develop Zig to include OOP?

theplumber 4y ago

This is doomed to fail b/c it uses semicolons. Why would you use semicolons in 2022?

cudgy 4y ago

Looks like Swift.

tpoacher 4y ago

groundhog () { s/rust/carbon/g ; }