20 ms·

Will Carbon Replace C++?

130 points by redbell 4y ago

SleepyMyroslav 4y ago
Low effort take from gamedev: to start talking about replacing anything Carbon needs to start presenting 'solutions'. The only thing they presented so far is their inability to work with others.
v3ss0n 4y ago
It was never heard after announcement. Really doubt anyone need it .
- SoylentOrange 4y ago
  There are many well known problems with C++, not least of which are the long compile times, exception handling, and dependency handling. Anyone who has worked with a sufficiently large C++ code base has run into these issues. The overwhelmingly negative comments here on HN remind me of the pushback that Rust Linux kernel modules received on HN when they were first announced around 2015/2016. Now they’re seen a much loved feature (I understand they solve different problems so the analogy isn’t perfect). I’m not confident that Carbon can be used to solve the issues that arise in large C++ projects as I’ve never tried it but that’s very different from pretending C++ is some kind of perfect language that doesn’t have these flaws and doesn’t need fixing.
  - micropresident 4y ago
    C++'s compile times are caused by design issues. Dlang compiles nearly instantaneously (for example). Lack of modules, and abiguities in the syntax are roughly what causes it.
  - PaulDavisThe1st 4y ago
    1. Long compile times tend to reflect headers, which are substantially addressable without a new language. 2. exception handling ... meh, i can't take this seriously. There's no ideal exception handling and if this is what is grinding your project to a halt, you've got bigger problems. 3. dependency handling ... if you mean "prepackaged libraries" then I'll repeat again that I don't want solutions to this baked into the language
TheRealPomax 4y ago
The article is about creating a potential successor to C++ in the same way JavaScript lead to TypeScript, or Java lead to Kotlin, or C lead to C++, and in giving those examples immediately undermining its own thought because none of those replaced the thing they came out of. Heck looking at whose still writing new code bases in what, C++ didn't even replace C, and Swift didn't replace Objective C. C++ and Switft just became "more dominant". So based on the article's own observation: no, of course not. The more interesting question is "will it stand on its own?" to which the answer is "only if it actually solves so many problems with the thing it's trying to supplant that it makes sense to give it a serious try". And C++ just... doesn't have that many real problems. It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language. Pretending you can replace C++ is like pretending you can replace cars. Not just "create EVs" but straight up replace cars. Good luck, you won't succeed if that's your goal, so hopefully you realise you need to focus on making a decent language that some folks might consider using instead of C++ for some of their work, instead of creating "the successor to C++".
- hulitu 4y ago
  > or C lead to C++, As "Unix haters handbook" says: C++ is to C, what lung cancer is to lung.
  - TheRealPomax 4y ago
    A profoundly idiotic statement, but on-brand for that manifesto.
  - RcouF1uZ4gsC 4y ago
    > As "Unix haters handbook" says As they compile their C code using a compiler written in C++. (GCC and Clang are both written in C++).
    - jcranmer 4y ago
      To be fair, that wasn't true when the Unix haters handbook was written, almost 30 years ago.
andsoitis 4y ago
The core hypothesis is that for a replacement language to be successful, it cannot only be great for new projects. Besides building on and extending tooling already in wide usage, you want the successor language to interplay elegantly with existing code, affording things like gradual replacement. Of course, that also means that you’re making less of a leap, but considering the vast landscape of active C++ code based, I would put my money behind this successor language argument.
danpalmer 4y ago
No. Carbon is an experiment to solve Google's challenges with C++, which look very different to, say, the challenges of the games industry or those of embedded software development. C++ is widely used enough that it would take decades of sustained development specifically targeting replacing it across all the areas it is used to make a dent.
- nine_k 4y ago
  Indeed. C++ will be displaced (not replaced) by the usual suspects: Rust, Zig, Golang, maybe even niche languages like Nim in certain areas, where C++ used to be the only sane choice. It's a bit like Fortran has been displaced by C, C++, Julia, even Python (with Numpy / Scipy) from the realm of numeric code where it used to reign supreme. It does not mean that important Fortran code does not exist any more, or even that new Fortran code is not written every day. It just means that Fortran is no longer dominant, and in many areas is definitely not the first choice. Same is happening to C++.
  - humanrebar 4y ago
    New Fortran is written all the time though. It might even be as much Fortran as was written in it's heyday. Programming is much, much bigger than it used to be.
    - nine_k 4y ago
      Certainly! Fortran is just not the only game in the numerical town, and likely it's not dominant any more, but it's alive and kicking. (Well, new Cobol code gets written.)
  - BenFrantzDale 4y ago
    As one data point: we are replacing Golang with C++ for homogeneity and not-weirdness. C++ has problems but it is very good at scaling and being boring, which is a good thing.
- deleted 4y ago
  [deleted]
staunton 4y ago
There is nothing to replace here. You should only start a new project in C++ if you absolutely have to, and if you really have to, perhaps due to legacy code, then complicating your smoldering dumpsterfire of a build system even more with this stuff is masochistic at best. Meanwhile, that dumpsterfire will burn on for maybe a century and people will have to keep "learning" C++. The only way to make this situation less painful is to finally stop trying to incorporate into C++ every new language that comes out.
- klodolph 4y ago
  The main selling point of Carbon is direct C++ interop, which is extremely rare and makes Carbon unique.
  - staunton 4y ago
    Yes. I believe that doesn't affect my argument. Instead of the ~4 programing languages found within C++20 you would be adding one more to the codebase. Does that sound like a good idea? Maybe my comment was too harsh. It's great someone's trying to make the C++ situation better. I hope they succeed. I just think they won't and C++ should go the way of C and stop "evolving", while this thing is very similar in spirit to blowing it up even further. (I've actually liked working with C++ for the past 15 years, but not because it's productive but for the stockholmy "challenge" of it)
    - pjmlp 4y ago
      I bet that are plenty of dialects in Python 3.11, Java 20, C# 12, C23.... That is what happens when languages stick around for decades
      - staunton 4y ago
        Thing is, C++ really is special in that way. I would say C is at most 2 languages (maybe not even that, or most legacy code is already the "newer" of those), Python is at most 2.5 languages (subtract one because Python 2 is no longer supported in 3). C# and Java have a better shot in this sad competition but still, it's not like you're not supposed to be using 50% of those languages original features anymore.
jcranmer 4y ago
I suppose Betteridge's Law of Headlines provides the answer, but the article doesn't even do a great job of attempting to answer the question.
bradhe 4y ago
No. Next question, please?
ape4 4y ago
Maybe there are too many (C++)++ languages? So its too hard to pick a winner.
asow92 4y ago
> Dart is a language on top of JavaScript Isn't Dart a compiled language that can be compiled to JS via dart2js and not "on top of JavaScript"?
- giancarlostoro 4y ago
  Originally it was built on top of v8 itself if I'm not mistaekn, so the author might be referencing some historical knowledge that has kind of changed.
  - mraleph 4y ago
    > it was built on top of v8 Was never built on top of V8 in any shape of form. Dart VM does not even share any code with V8. Dart 1 was designed by people who originally started V8 (Lars Bak and Kasper Lund), that's the only connection.
    - giancarlostoro 4y ago
      Seems I too may be misremembering as well, I do know there used to be a custom Chromium build that included a Dart runtime so I assumed that was why v8 was used. But I remember now, there was an original effort to include dart in Chrome which met no fanfare.
- synergy20 4y ago
  yes, Dart has little to do with JS now, it's made for Flutter for the most part nowadays, and it is great.
- doodlesdev 4y ago
  Yes, at first it reminds me a bit of Haxe [0], which compiles to a multitude of languages. Originally it was made to "replace" JavaScript, there's Angular Dart for instance as an example of what that would work like. But nowadays Dart can compile to JavaScript or "Dart Native" [2] which instead of Haxe reminds much more of Java or C# since it runs inside a VM in JIT mode. It can run on ARM32, ARM64 and x84_64 natively as machine code through the Dart runtime when compiled AOT and performance is of course much better than compiling to JavaScript so you can see why it's a really interesting option for the development of Flutter which targets web, desktop, and mobile. You write the code once and get to have JIT for development with hot reloading, debugging and live metrics, and AOT compilation for your desktop and mobile targets while also getting a JavaScript bundle for your web target. [0]: https://haxe.org/ https://haxe.org/ [1]: https://github.com/angulardart https://github.com/angulardart [2]: https://dart.dev/overview#platform https://dart.dev/overview#platform
synergy20 4y ago
Help improving c++ first please. then create a profile for whatever Google needs instead. and also please create a C profile off C++ that is safer than C, and make C a true subset instead of diverging them even further.
- steveklabnik 4y ago
  Carbon was seemingly borne out of Google’s frustrations that they could not get the C++ committee to agree with their desired improvements and direction for the future. That is, they’ve already been doing what you ask. Yet here we are.
  - tialaramex 4y ago
    Specifically, P2137 spells out what key people (not only at Google) wanted and WG21 (the C++ Committee) said "No". Well I mean, as a whole, several of the P2137 authors are WG21 members, this was not a decision made with one unified voice. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p21... Carbon has a few interesting ideas which I hope survive in at least some weird niche languages even if the Carbon experiment fails, because they deserve to be known to people who invent programming languages - some future Rust replacement might find a use for them for example. But the most important thing Carbon got right that most of these C++ Successor languages did not, was that it understood why Rust is safe. Rust's safety is not primarily about the technology, although of course the technology is important, it's about the Culture, and Carbon understood that.
deleted 4y ago
[deleted]
vasilipupkin 4y ago
why does every attempt to replace C++ make syntax of the new language significantly uglier than C++? why do I need to type "let" and "fn", etc? why not make the syntax very similar if you actually want to make it easy to migrate?
- audunw 4y ago
  It's somewhat related to solving one of C/C++'s real problems: the syntax is very context sensitive. That makes tool development harder. Personally I think it's great that most new languages seem to move in roughly the same direction when it comes to syntax.. like "x: int" instead of "int x" for variable declaration, and something similar on functions "fn", "fun" or "function" prefix before functions "let"/"const" for constants and/or single assignment variables "var" for variables etc. I think there's a reason so many language designers are making similar decisions on these things.
  - vasilipupkin 4y ago
    why is this great? what's the reason? x: int is significantly less readable than int x and involves typing one more character. Why? what is the advantage of type int fn foo versus int foo() {} ? why type var in front of a variable when int x makes it clear its a variable?
    - steveklabnik 4y ago
      “Significantly less readable” is subjective. It is simpler to parse, and degrades better with type inference. That’s 90% of it, I’d imagine.
      - vasilipupkin 4y ago
        sure, well, it's not subjective if you have to type more characters to basically achieve the same thing. I guess I just don't really understand why you have to fix C++ shortcomings while also changing things that work fine. Is there a C++ developer who is having trouble declaring variables as int x? By making big changes to syntax, you are just making it less likely this ever gets truly adopted.
zwieback 4y ago
If you add "... in field [x] or application space [y]" to the question it might lead to a useful discussion but as-is the question is too broad.
taraharris 4y ago
Has anyone else looked at Herb Sutter's cpp2? For those that don't use C++, Herb is chair of the ISO C++ standards committee, and holds the position of "native languages architect" at Microsoft. https://twitter.com/herbsutter/status/1609307537261617154 https://twitter.com/herbsutter/status/1609307537261617154 This is a good introductory talk on cpp2 by Sutter at CppCon three months ago, where he demonstrates cppfront, the cpp2 -> C++ transpiler. One of the things I like about it is that the code it generates is human-readable and fully backwards-compatible with C++. If you use cpp2 in your project and end up not liking it, you still have the same (very reasonable) C++ code that you'd write by hand today if you followed the guidelines you're supposed to already. https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY I think this is very promising, and I'm interested in using it my next project. We don't need a total replacement for C++, we just need to let out the awesome language that's always been hiding inside it.
- lanza 4y ago
  He didn't staff a team of compiler engineers to do it. Doesn't matter how good it is when mature languages that reach the mainstream all have compilers funded by 10 people at a tech giant and cppfront is just Sutter screwing around in his free time. Google threw the weight of their top C++ engineers behind Carbon. It's happening. That's really what matters in the world of programming languages. Not how good it is.
  - taraharris 4y ago
    Just watch what happens to Google and their ad revenues in this downturn, by the way. I knew people that were hyping Fuschia, and then Google cut deepest from that on their first round of layoffs. It wouldn't be a shock to me if they yank out the carpet from this Carbon thing one day, or have it limp along like Dart. In summary, Google can do what it wants, but I'll just keep using C++ no matter what it does. I spend all my time in and on HaikuOS now, so for me C++ here here to stay :)
    - pjmlp 4y ago
      Fuschia is shipping on Nest devices though.
matt3210 4y ago
The next step in software is a language optimized for ai generation. Rust and carbon are for humans and are a side step at best
- Borg3 4y ago
  I love such comments. Humans got here because they are able to solve abstract problems and analitical thinking. Go ahead and pass it all to AI. Whats left? An useless consumer... (go go Skynet :)
deagle50 4y ago
Low effort TL;DR of the CppNorth presentation to drive traffic to a commercial site.
deleted 4y ago
[deleted]
pjmlp 4y ago
They keep pointing out Typescript and Kotlin, without understanding that the first only adds type declarations, while the second fakes to be Java at the JVM bytecode level (try javap on a .class generated by kotlinc). If Carbon ever goes beyond an experiment it will be for Google's own internal purposes.
- sdkgames 4y ago
  >without understanding that the first only adds type declarations https://www.typescriptlang.org/docs/handbook/enums.html https://www.typescriptlang.org/docs/handbook/enums.html
  - pjmlp 4y ago
    Not forever if this ever comes through, https://github.com/Jack-Works/proposal-enum https://github.com/Jack-Works/proposal-enum
  - iudqnolq 4y ago
    Barely https://www.typescriptlang.org/play?ssl=12&ssc=1&pln=12&pc=4#code/PTAEHUFMBsGMHsC2lQBd5oBYoCoE8AHSAZVgCcBLA1UABWgEM8BzM+AVwDsATAGiwoBnUENANQAd0gAjQRVSQAUCEmYKsTKGYUAbpGF4OY0BoadYKdJMoL+gzAzIoz3UNEiPOofEVKVqAHSKymAAmkYI7NCuqGqcANag8ABmIjQUXrFOKBJMggBcISGgoAC0oACCbvCwDKgU8JkY7p7ehCTkVDQS2E6gnPCxGcwmZqDSTgzxxWWVoASMFmgYkAAeRJTInN3ymj4d-jSCeNsMq-wuoPaOltigAKoASgAywhK7SbGQZIIz5VWCFzSeCrZagNYbChbHaxUDcCjJZLfSDbExIAgUdxkUBIursJzCFJtXydajBFHsRCgABi8AwAG9FCUSgAhRyKAC+JSAA https://www.typescriptlang.org/play?ssl=12&ssc=1&pln=12&pc=4...
- jeroenhd 4y ago
  > while the second fakes to be Java at the JVM bytecode level (try javap on a .class generated by kotlinc) What's wrong with that? All of my gripes with Java, other than the way they did their generics, are at the language level. The bytecode and underlying VM are works of art. Kotlin adds reification to the JVM and adds explicit nullability annotation as a compile time error rather than a warning, which solves my worst annoyances with Java. I'd still use Kotlin if all it did was transpile itself into .java files and call the compiler for me.
andrewstuart 4y ago
Why would it use let to define a const?
- favorited 4y ago
  It's not an uncommon choice in modern languages. Rust & Swift both use `let` to mean an immutable binding.
  - MBCook 4y ago
    JS too.
    - favorited 4y ago
      JS has a `let` keyword, but you can reassign the value through it. `let a = 5; a = 6;` is valid JavaScript, and the value of `a` would be 6.
  - pjmlp 4y ago
    Modern going all the way back to the 1970's in ML, and a common way to declare variables in BASIC.
andrewstuart 4y ago
If the idea is to retain the modern features, focus attention on them and peel off all the superseded old stuff then I’m all for it. Seems to me languages that focus on backward compatibility end up with a great modern core but it kinda gets lost because how do you know that the modern core? Developers learning can’t know what’s new and best and recognize what’s old noise. It has to be said though that googles reputation for killing projects overshadows anything they do.
dmead 4y ago
No
Animats 4y ago
Reading the article, it mostly looks like syntactic sugar changes. Is there more under the hood? Most of C++'s problems are on the data side. Newer versions of C++ address the big issues (How big is it? Who deletes it? Who locks it?) but only by adding features, not by deleting anything. What is Carbon doing in those areas?
martin1975 4y ago
Almost always the probably, almost certain answer to an essay like this is a "no." Google could focus on making C++/Rust interop as smooth as Carbon's instead.
- luuuzeta 4y ago
  >Almost always the probably, almost certain answer to an essay like this is a "no." Betteridge's law of headlines
  - martin1975 4y ago
    You're well informed, sir/madam. :)
- tonfa 4y ago
  Like https://github.com/google/crubit https://github.com/google/crubit ?
  - martin1975 4y ago
    Exactly. Thx for the heads up.
palata 4y ago
One thing is that creating a new language is super cool. If I was important enough at Google to get a team for that, I would! And I would be biased when answering questions like "is it really needed?". That's probably the reason why there is a new language created every second day. Curious to see if one will "win", though.
i-use-nixos-btw 4y ago
Any successor to C++ will necessarily need to be built around safety from day one. Carbon did not do that - it merely hopes to put safety in at a later stage. So no, I don’t think Carbon will replace C++. I will be very surprised if a C++ successor will be a new language. I think it will be a frontend to C++ that cleans up the syntax, has much stricter rules around UB, and can rely on C++ as its unsafe counterpart. C++ itself will never be safe - it can’t be while maintaining backwards compatibility, and even modern features (ranges, coroutines) provide a wide range of new lifetime nightmares. A new frontend could solve a lot of that, while allowing unsafe “trust me bro” code to be written in C++. There’s the “enable new features in a file with pragmas” idea, too, which could be promising. But I’m not convinced.
- fortran77 4y ago
  Unsafe rust code is "trust me bro" too
  - lpapez 4y ago
    Except it is not though. Unsafe blocks are "hey check this extra carefully because it might be unsafe" instead of everything being implicitly unsafe everywhere.
  - i-use-nixos-btw 4y ago
    Exactly! And yet Rust gets a reputation of safety: the boundary between safe and unsafe is formal, and that opens up huge possibilities for metrics, compliance, and targeted testing. That’s what I’d shoot for.
    - armchairhacker 4y ago
      People say this a lot. But formal methods is really hard and really tedious. Especially if you can't write whatever you're trying to prove safe in safe rust, it's going to be even harder and more tedious. To give perspective: CompCert (a C compiler with formally-proven semantics, arguably one of the largest formally-proven programs to date) has been developed for decades and still does not support all C99 features; it and sel4 (a formally-verified safe microkernel) are both single-core because proving properties in complex multicore interactions has basically not been done (sel4 actually does have a multicore implementation, but it's not yet formally verified). Safety, performance, ease-of-use: pick two. If we really care about safety, the easiest solution for many is to just use a language like Java or Python where everything is boxed and checked and there is no truly unsafe code. Safe Rust strikes a really nice balance of being almost formally-proven safe, almost as performant as unsafe Rust/C++, and almost as easy to use as more general-purpose-languages (the extent of the third "almost" varies widely among developers).
anonuser123456 4y ago
I cannot help but wonder if modern language design is a bit like designing better punch card formats in the 70s. If we can teach AI to program in C/ASM will language features matter?
MathMonkeyMan 4y ago
Suppose you're a big company with a ton of C++ code. You're never going to rewrite it all. It wouldn't even be a good idea. If only there were a way to write new code in a new language, mostly unconstrained by the long history of C++, but let the two languages share a toolchain, and maintain a logical interface compatibility layer. Not just linking the same ABI, but compatible types, functions, meta-functions (templates), etc. Then you could implement all of the features and static checks of your dreams, and modify the language and its implementation to make those features/checks more powerful and easy to implement. My guess is that's the idea. If you weren't a huge company with zillions invested in countless lines of C++, you wouldn't need to consider this. And, regardless, it's a neat idea.
- MBCook 4y ago
  There was a very interesting presentation about how Apple was trying to give Swift a stable ABI that provided forward looking stability. Apple has a LOT of C/C++/Obj-C/Obj-C++ code. And they certainly have the resources/need for such a thing. I wonder if what they’re doing could be extended to make integrating new Swift code easier with all the existing non-Swift stuff as it slowly got rewritten. I’m not suggesting everyone switch to Swift, merely that someone may already be doing something like you’re talking about.
  - pjmlp 4y ago
    They not only were trying, they made it, it was made stable in Swift 5.
- humanrebar 4y ago
  Yeah, but doesn't that approach presume you have a monorepo or something already? Seems like converting a native python extension to the new language will just break all the downstream users of that package who do not already have the new toolchain set up. That's exactly what happened with the cryptography package when it converted to Rust. And that's just an example. What about all the projects shipping to embedded systems, tiny Linux distros, specialty proprietary OSs, and so on?
pciexpgpu 4y ago
There needs to be a new PL word for languages that work side-by-side (SxS?) with a legacy language. Not to replace it but coexist peacefully. TypeScript, Kotlin, Swift and even C++ are all great examples of SxS languages. Carbon could be a great SxS language with enough inertia building up over time: still never aim to replace C++ (a fool’s errand) but always work in conjunction with large C++ codebases. It’s such a great pleasure to write things in TS while always being able to use mix-match JS libraries and tooling and debugging. I hope Carbon achieves a similar result moving the industry and engineers forward without resorting to “languages are religions” tediousness.
IOT_Apprentice 4y ago
Dumb question. If you have language servers and AI systems like ChatGPT can’t you train them to rewrite c++ code to a different language? Can’t you also train it to detect pointer errors as well?
doubtfuluser 4y ago
As long as we have articles claiming language xyz replaces C++, c++ will be fine. The day none writes about c++ anymore is when it will be replaced.
mnemotronic 4y ago
C++ has become a feature magnet and punctuation character gumbo. How long before the Carbon language committee decides they need to add "cool" obscure features found in other languages and thereby needlessly complicate it to death.
- pjmlp 4y ago
  Just wait if generic keywords make into Rust, with ? prefixes.
return_to_monke 4y ago
> Dart is a language on top of JavaScript and other languages with the mission to be the main language for the Flutter project, addressing the creation of cross-platform apps. The JavaScript part is a factual error. Dart can compile to js. Dart can also soon compile to wasm, but most of dart code runs on the dart VM and has nothing to do with JS.
pjmlp 4y ago
Not really, at least not during this decade. > Note that we don't expect to finish the 0.1 language work in 2023. Our goal is to make sufficient progress that we can complete it in 2024, but there are still many things that can go wrong and cause significant delays. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/roadmap.md https://github.com/carbon-language/carbon-lang/blob/trunk/do... So while an interesting experiment, and it can even get an ecossytem of its own, provided it doesn't go out of steam, it is still quite far from that.
blippage 4y ago
Also worth reading: The Year [2022] of C++ Successor Languages [0] "interface" seems a step forward, amongst other things. I'd like to see Sumtypes (aka Algebraic Data Types) without the pain. And recursive data structures. And co-routines for mortals. I'd be tempted to check out Carbon at some point. I am mistrustful of Google, though, what with their whole telemetry idea in Go. A good outcome would be if Carbon pollinated some ideas into C++, acting as a testbed. I think that C++ has steered itself exceptionally well, actually. It has aimed at stability rather than "move fast and break things". It has avoided the missteps of Raku (Perl 6), Python 3. The fact that people "hate" C++ is on balance more of a feature than a bug. The newer languages have projects which sometimes mandate nightly builds (I'm looking at you, Rust and Zig). It feels that you're trying to build a house on a sandbank. I hope that C++ never gets a package manager/build system. I'm not convinced that they've ever really been done properly or stably (Python seems to have a plethora of install methods, for example), and it leads to the mentality of kitchen-sinking dependencies. [0] https://accu.org/journals/overload/30/172/teodorescu/ https://accu.org/journals/overload/30/172/teodorescu/
- lizmat 4y ago
  > It has avoided the missteps of Raku (Perl 6) It is unclear to me what missteps you are referring to?
  - blippage 4y ago
    It took over a decade to produce. After all that, it was pretty damn slow, and I suspect that many people thought it was too slow to be worth using.
    - lizmat 4y ago
      Well, performance has been improved by several orders of magnitude since the first release. So maybe it's time to look at https://raku.org https://raku.org again (or first have a look at its new documentation site https://docs.raku.org https://docs.raku.org)

130 points by redbell 4y ago

Low effort take from gamedev: to start talking about replacing anything Carbon needs to start presenting 'solutions'. The only thing they presented so far is their inability to work with others.

v3ss0n 4y ago

It was never heard after announcement. Really doubt anyone need it .

SoylentOrange 4y ago
There are many well known problems with C++, not least of which are the long compile times, exception handling, and dependency handling. Anyone who has worked with a sufficiently large C++ code base has run into these issues. The overwhelmingly negative comments here on HN remind me of the pushback that Rust Linux kernel modules received on HN when they were first announced around 2015/2016. Now they’re seen a much loved feature (I understand they solve different problems so the analogy isn’t perfect). I’m not confident that Carbon can be used to solve the issues that arise in large C++ projects as I’ve never tried it but that’s very different from pretending C++ is some kind of perfect language that doesn’t have these flaws and doesn’t need fixing.
- micropresident 4y ago
  C++'s compile times are caused by design issues. Dlang compiles nearly instantaneously (for example). Lack of modules, and abiguities in the syntax are roughly what causes it.
- PaulDavisThe1st 4y ago
  1. Long compile times tend to reflect headers, which are substantially addressable without a new language. 2. exception handling ... meh, i can't take this seriously. There's no ideal exception handling and if this is what is grinding your project to a halt, you've got bigger problems. 3. dependency handling ... if you mean "prepackaged libraries" then I'll repeat again that I don't want solutions to this baked into the language

TheRealPomax 4y ago

The article is about creating a potential successor to C++ in the same way JavaScript lead to TypeScript, or Java lead to Kotlin, or C lead to C++, and in giving those examples immediately undermining its own thought because none of those replaced the thing they came out of. Heck looking at whose still writing new code bases in what, C++ didn't even replace C, and Swift didn't replace Objective C. C++ and Switft just became "more dominant". So based on the article's own observation: no, of course not. The more interesting question is "will it stand on its own?" to which the answer is "only if it actually solves so many problems with the thing it's trying to supplant that it makes sense to give it a serious try". And C++ just... doesn't have that many real problems. It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language. Pretending you can replace C++ is like pretending you can replace cars. Not just "create EVs" but straight up replace cars. Good luck, you won't succeed if that's your goal, so hopefully you realise you need to focus on making a decent language that some folks might consider using instead of C++ for some of their work, instead of creating "the successor to C++".

hulitu 4y ago
> or C lead to C++, As "Unix haters handbook" says: C++ is to C, what lung cancer is to lung.
- TheRealPomax 4y ago
  A profoundly idiotic statement, but on-brand for that manifesto.
- RcouF1uZ4gsC 4y ago
  > As "Unix haters handbook" says As they compile their C code using a compiler written in C++. (GCC and Clang are both written in C++).
  - jcranmer 4y ago
    To be fair, that wasn't true when the Unix haters handbook was written, almost 30 years ago.

andsoitis 4y ago

The core hypothesis is that for a replacement language to be successful, it cannot only be great for new projects. Besides building on and extending tooling already in wide usage, you want the successor language to interplay elegantly with existing code, affording things like gradual replacement. Of course, that also means that you’re making less of a leap, but considering the vast landscape of active C++ code based, I would put my money behind this successor language argument.

danpalmer 4y ago

No. Carbon is an experiment to solve Google's challenges with C++, which look very different to, say, the challenges of the games industry or those of embedded software development. C++ is widely used enough that it would take decades of sustained development specifically targeting replacing it across all the areas it is used to make a dent.

nine_k 4y ago
Indeed. C++ will be displaced (not replaced) by the usual suspects: Rust, Zig, Golang, maybe even niche languages like Nim in certain areas, where C++ used to be the only sane choice. It's a bit like Fortran has been displaced by C, C++, Julia, even Python (with Numpy / Scipy) from the realm of numeric code where it used to reign supreme. It does not mean that important Fortran code does not exist any more, or even that new Fortran code is not written every day. It just means that Fortran is no longer dominant, and in many areas is definitely not the first choice. Same is happening to C++.
- humanrebar 4y ago
  New Fortran is written all the time though. It might even be as much Fortran as was written in it's heyday. Programming is much, much bigger than it used to be.
  - nine_k 4y ago
    Certainly! Fortran is just not the only game in the numerical town, and likely it's not dominant any more, but it's alive and kicking. (Well, new Cobol code gets written.)
- BenFrantzDale 4y ago
  As one data point: we are replacing Golang with C++ for homogeneity and not-weirdness. C++ has problems but it is very good at scaling and being boring, which is a good thing.
deleted 4y ago
[deleted]

staunton 4y ago

There is nothing to replace here. You should only start a new project in C++ if you absolutely have to, and if you really have to, perhaps due to legacy code, then complicating your smoldering dumpsterfire of a build system even more with this stuff is masochistic at best. Meanwhile, that dumpsterfire will burn on for maybe a century and people will have to keep "learning" C++. The only way to make this situation less painful is to finally stop trying to incorporate into C++ every new language that comes out.

klodolph 4y ago
The main selling point of Carbon is direct C++ interop, which is extremely rare and makes Carbon unique.
- staunton 4y ago
  Yes. I believe that doesn't affect my argument. Instead of the ~4 programing languages found within C++20 you would be adding one more to the codebase. Does that sound like a good idea? Maybe my comment was too harsh. It's great someone's trying to make the C++ situation better. I hope they succeed. I just think they won't and C++ should go the way of C and stop "evolving", while this thing is very similar in spirit to blowing it up even further. (I've actually liked working with C++ for the past 15 years, but not because it's productive but for the stockholmy "challenge" of it)
  - pjmlp 4y ago
    I bet that are plenty of dialects in Python 3.11, Java 20, C# 12, C23.... That is what happens when languages stick around for decades
    - staunton 4y ago
      Thing is, C++ really is special in that way. I would say C is at most 2 languages (maybe not even that, or most legacy code is already the "newer" of those), Python is at most 2.5 languages (subtract one because Python 2 is no longer supported in 3). C# and Java have a better shot in this sad competition but still, it's not like you're not supposed to be using 50% of those languages original features anymore.

jcranmer 4y ago

I suppose Betteridge's Law of Headlines provides the answer, but the article doesn't even do a great job of attempting to answer the question.

bradhe 4y ago

No. Next question, please?

ape4 4y ago

Maybe there are too many (C++)++ languages? So its too hard to pick a winner.

asow92 4y ago

> Dart is a language on top of JavaScript Isn't Dart a compiled language that can be compiled to JS via dart2js and not "on top of JavaScript"?

giancarlostoro 4y ago
Originally it was built on top of v8 itself if I'm not mistaekn, so the author might be referencing some historical knowledge that has kind of changed.
- mraleph 4y ago
  > it was built on top of v8 Was never built on top of V8 in any shape of form. Dart VM does not even share any code with V8. Dart 1 was designed by people who originally started V8 (Lars Bak and Kasper Lund), that's the only connection.
  - giancarlostoro 4y ago
    Seems I too may be misremembering as well, I do know there used to be a custom Chromium build that included a Dart runtime so I assumed that was why v8 was used. But I remember now, there was an original effort to include dart in Chrome which met no fanfare.
synergy20 4y ago
yes, Dart has little to do with JS now, it's made for Flutter for the most part nowadays, and it is great.
doodlesdev 4y ago
Yes, at first it reminds me a bit of Haxe [0], which compiles to a multitude of languages. Originally it was made to "replace" JavaScript, there's Angular Dart for instance as an example of what that would work like. But nowadays Dart can compile to JavaScript or "Dart Native" [2] which instead of Haxe reminds much more of Java or C# since it runs inside a VM in JIT mode. It can run on ARM32, ARM64 and x84_64 natively as machine code through the Dart runtime when compiled AOT and performance is of course much better than compiling to JavaScript so you can see why it's a really interesting option for the development of Flutter which targets web, desktop, and mobile. You write the code once and get to have JIT for development with hot reloading, debugging and live metrics, and AOT compilation for your desktop and mobile targets while also getting a JavaScript bundle for your web target. [0]: https://haxe.org/ https://haxe.org/ [1]: https://github.com/angulardart https://github.com/angulardart [2]: https://dart.dev/overview#platform https://dart.dev/overview#platform

synergy20 4y ago

Help improving c++ first please. then create a profile for whatever Google needs instead. and also please create a C profile off C++ that is safer than C, and make C a true subset instead of diverging them even further.

steveklabnik 4y ago
Carbon was seemingly borne out of Google’s frustrations that they could not get the C++ committee to agree with their desired improvements and direction for the future. That is, they’ve already been doing what you ask. Yet here we are.
- tialaramex 4y ago
  Specifically, P2137 spells out what key people (not only at Google) wanted and WG21 (the C++ Committee) said "No". Well I mean, as a whole, several of the P2137 authors are WG21 members, this was not a decision made with one unified voice. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p21... Carbon has a few interesting ideas which I hope survive in at least some weird niche languages even if the Carbon experiment fails, because they deserve to be known to people who invent programming languages - some future Rust replacement might find a use for them for example. But the most important thing Carbon got right that most of these C++ Successor languages did not, was that it understood why Rust is safe. Rust's safety is not primarily about the technology, although of course the technology is important, it's about the Culture, and Carbon understood that.

deleted 4y ago

[deleted]

vasilipupkin 4y ago

why does every attempt to replace C++ make syntax of the new language significantly uglier than C++? why do I need to type "let" and "fn", etc? why not make the syntax very similar if you actually want to make it easy to migrate?

audunw 4y ago
It's somewhat related to solving one of C/C++'s real problems: the syntax is very context sensitive. That makes tool development harder. Personally I think it's great that most new languages seem to move in roughly the same direction when it comes to syntax.. like "x: int" instead of "int x" for variable declaration, and something similar on functions "fn", "fun" or "function" prefix before functions "let"/"const" for constants and/or single assignment variables "var" for variables etc. I think there's a reason so many language designers are making similar decisions on these things.
- vasilipupkin 4y ago
  why is this great? what's the reason? x: int is significantly less readable than int x and involves typing one more character. Why? what is the advantage of type int fn foo versus int foo() {} ? why type var in front of a variable when int x makes it clear its a variable?
  - steveklabnik 4y ago
    “Significantly less readable” is subjective. It is simpler to parse, and degrades better with type inference. That’s 90% of it, I’d imagine.
    - vasilipupkin 4y ago
      sure, well, it's not subjective if you have to type more characters to basically achieve the same thing. I guess I just don't really understand why you have to fix C++ shortcomings while also changing things that work fine. Is there a C++ developer who is having trouble declaring variables as int x? By making big changes to syntax, you are just making it less likely this ever gets truly adopted.

zwieback 4y ago

If you add "... in field [x] or application space [y]" to the question it might lead to a useful discussion but as-is the question is too broad.

taraharris 4y ago

Has anyone else looked at Herb Sutter's cpp2? For those that don't use C++, Herb is chair of the ISO C++ standards committee, and holds the position of "native languages architect" at Microsoft. https://twitter.com/herbsutter/status/1609307537261617154 https://twitter.com/herbsutter/status/1609307537261617154 This is a good introductory talk on cpp2 by Sutter at CppCon three months ago, where he demonstrates cppfront, the cpp2 -> C++ transpiler. One of the things I like about it is that the code it generates is human-readable and fully backwards-compatible with C++. If you use cpp2 in your project and end up not liking it, you still have the same (very reasonable) C++ code that you'd write by hand today if you followed the guidelines you're supposed to already. https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY I think this is very promising, and I'm interested in using it my next project. We don't need a total replacement for C++, we just need to let out the awesome language that's always been hiding inside it.

lanza 4y ago
He didn't staff a team of compiler engineers to do it. Doesn't matter how good it is when mature languages that reach the mainstream all have compilers funded by 10 people at a tech giant and cppfront is just Sutter screwing around in his free time. Google threw the weight of their top C++ engineers behind Carbon. It's happening. That's really what matters in the world of programming languages. Not how good it is.
- taraharris 4y ago
  Just watch what happens to Google and their ad revenues in this downturn, by the way. I knew people that were hyping Fuschia, and then Google cut deepest from that on their first round of layoffs. It wouldn't be a shock to me if they yank out the carpet from this Carbon thing one day, or have it limp along like Dart. In summary, Google can do what it wants, but I'll just keep using C++ no matter what it does. I spend all my time in and on HaikuOS now, so for me C++ here here to stay :)
  - pjmlp 4y ago
    Fuschia is shipping on Nest devices though.

matt3210 4y ago

The next step in software is a language optimized for ai generation. Rust and carbon are for humans and are a side step at best

Borg3 4y ago
I love such comments. Humans got here because they are able to solve abstract problems and analitical thinking. Go ahead and pass it all to AI. Whats left? An useless consumer... (go go Skynet :)

deagle50 4y ago

Low effort TL;DR of the CppNorth presentation to drive traffic to a commercial site.

deleted 4y ago

[deleted]

pjmlp 4y ago

They keep pointing out Typescript and Kotlin, without understanding that the first only adds type declarations, while the second fakes to be Java at the JVM bytecode level (try javap on a .class generated by kotlinc). If Carbon ever goes beyond an experiment it will be for Google's own internal purposes.

sdkgames 4y ago
>without understanding that the first only adds type declarations https://www.typescriptlang.org/docs/handbook/enums.html https://www.typescriptlang.org/docs/handbook/enums.html
- pjmlp 4y ago
  Not forever if this ever comes through, https://github.com/Jack-Works/proposal-enum https://github.com/Jack-Works/proposal-enum
- iudqnolq 4y ago
  Barely https://www.typescriptlang.org/play?ssl=12&ssc=1&pln=12&pc=4#code/PTAEHUFMBsGMHsC2lQBd5oBYoCoE8AHSAZVgCcBLA1UABWgEM8BzM+AVwDsATAGiwoBnUENANQAd0gAjQRVSQAUCEmYKsTKGYUAbpGF4OY0BoadYKdJMoL+gzAzIoz3UNEiPOofEVKVqAHSKymAAmkYI7NCuqGqcANag8ABmIjQUXrFOKBJMggBcISGgoAC0oACCbvCwDKgU8JkY7p7ehCTkVDQS2E6gnPCxGcwmZqDSTgzxxWWVoASMFmgYkAAeRJTInN3ymj4d-jSCeNsMq-wuoPaOltigAKoASgAywhK7SbGQZIIz5VWCFzSeCrZagNYbChbHaxUDcCjJZLfSDbExIAgUdxkUBIursJzCFJtXydajBFHsRCgABi8AwAG9FCUSgAhRyKAC+JSAA https://www.typescriptlang.org/play?ssl=12&ssc=1&pln=12&pc=4...
jeroenhd 4y ago
> while the second fakes to be Java at the JVM bytecode level (try javap on a .class generated by kotlinc) What's wrong with that? All of my gripes with Java, other than the way they did their generics, are at the language level. The bytecode and underlying VM are works of art. Kotlin adds reification to the JVM and adds explicit nullability annotation as a compile time error rather than a warning, which solves my worst annoyances with Java. I'd still use Kotlin if all it did was transpile itself into .java files and call the compiler for me.

andrewstuart 4y ago

Why would it use let to define a const?

favorited 4y ago
It's not an uncommon choice in modern languages. Rust & Swift both use `let` to mean an immutable binding.
- MBCook 4y ago
  JS too.
  - favorited 4y ago
    JS has a `let` keyword, but you can reassign the value through it. `let a = 5; a = 6;` is valid JavaScript, and the value of `a` would be 6.
- pjmlp 4y ago
  Modern going all the way back to the 1970's in ML, and a common way to declare variables in BASIC.

andrewstuart 4y ago

If the idea is to retain the modern features, focus attention on them and peel off all the superseded old stuff then I’m all for it. Seems to me languages that focus on backward compatibility end up with a great modern core but it kinda gets lost because how do you know that the modern core? Developers learning can’t know what’s new and best and recognize what’s old noise. It has to be said though that googles reputation for killing projects overshadows anything they do.

dmead 4y ago

Animats 4y ago

Reading the article, it mostly looks like syntactic sugar changes. Is there more under the hood? Most of C++'s problems are on the data side. Newer versions of C++ address the big issues (How big is it? Who deletes it? Who locks it?) but only by adding features, not by deleting anything. What is Carbon doing in those areas?

martin1975 4y ago

Almost always the probably, almost certain answer to an essay like this is a "no." Google could focus on making C++/Rust interop as smooth as Carbon's instead.

luuuzeta 4y ago
>Almost always the probably, almost certain answer to an essay like this is a "no." Betteridge's law of headlines
- martin1975 4y ago
  You're well informed, sir/madam. :)
tonfa 4y ago
Like https://github.com/google/crubit https://github.com/google/crubit ?
- martin1975 4y ago
  Exactly. Thx for the heads up.

palata 4y ago

One thing is that creating a new language is super cool. If I was important enough at Google to get a team for that, I would! And I would be biased when answering questions like "is it really needed?". That's probably the reason why there is a new language created every second day. Curious to see if one will "win", though.

i-use-nixos-btw 4y ago

Any successor to C++ will necessarily need to be built around safety from day one. Carbon did not do that - it merely hopes to put safety in at a later stage. So no, I don’t think Carbon will replace C++. I will be very surprised if a C++ successor will be a new language. I think it will be a frontend to C++ that cleans up the syntax, has much stricter rules around UB, and can rely on C++ as its unsafe counterpart. C++ itself will never be safe - it can’t be while maintaining backwards compatibility, and even modern features (ranges, coroutines) provide a wide range of new lifetime nightmares. A new frontend could solve a lot of that, while allowing unsafe “trust me bro” code to be written in C++. There’s the “enable new features in a file with pragmas” idea, too, which could be promising. But I’m not convinced.

fortran77 4y ago
Unsafe rust code is "trust me bro" too
- lpapez 4y ago
  Except it is not though. Unsafe blocks are "hey check this extra carefully because it might be unsafe" instead of everything being implicitly unsafe everywhere.
- i-use-nixos-btw 4y ago
  Exactly! And yet Rust gets a reputation of safety: the boundary between safe and unsafe is formal, and that opens up huge possibilities for metrics, compliance, and targeted testing. That’s what I’d shoot for.
  - armchairhacker 4y ago
    People say this a lot. But formal methods is really hard and really tedious. Especially if you can't write whatever you're trying to prove safe in safe rust, it's going to be even harder and more tedious. To give perspective: CompCert (a C compiler with formally-proven semantics, arguably one of the largest formally-proven programs to date) has been developed for decades and still does not support all C99 features; it and sel4 (a formally-verified safe microkernel) are both single-core because proving properties in complex multicore interactions has basically not been done (sel4 actually does have a multicore implementation, but it's not yet formally verified). Safety, performance, ease-of-use: pick two. If we really care about safety, the easiest solution for many is to just use a language like Java or Python where everything is boxed and checked and there is no truly unsafe code. Safe Rust strikes a really nice balance of being almost formally-proven safe, almost as performant as unsafe Rust/C++, and almost as easy to use as more general-purpose-languages (the extent of the third "almost" varies widely among developers).

anonuser123456 4y ago

I cannot help but wonder if modern language design is a bit like designing better punch card formats in the 70s. If we can teach AI to program in C/ASM will language features matter?

MathMonkeyMan 4y ago

Suppose you're a big company with a ton of C++ code. You're never going to rewrite it all. It wouldn't even be a good idea. If only there were a way to write new code in a new language, mostly unconstrained by the long history of C++, but let the two languages share a toolchain, and maintain a logical interface compatibility layer. Not just linking the same ABI, but compatible types, functions, meta-functions (templates), etc. Then you could implement all of the features and static checks of your dreams, and modify the language and its implementation to make those features/checks more powerful and easy to implement. My guess is that's the idea. If you weren't a huge company with zillions invested in countless lines of C++, you wouldn't need to consider this. And, regardless, it's a neat idea.

MBCook 4y ago
There was a very interesting presentation about how Apple was trying to give Swift a stable ABI that provided forward looking stability. Apple has a LOT of C/C++/Obj-C/Obj-C++ code. And they certainly have the resources/need for such a thing. I wonder if what they’re doing could be extended to make integrating new Swift code easier with all the existing non-Swift stuff as it slowly got rewritten. I’m not suggesting everyone switch to Swift, merely that someone may already be doing something like you’re talking about.
- pjmlp 4y ago
  They not only were trying, they made it, it was made stable in Swift 5.
humanrebar 4y ago
Yeah, but doesn't that approach presume you have a monorepo or something already? Seems like converting a native python extension to the new language will just break all the downstream users of that package who do not already have the new toolchain set up. That's exactly what happened with the cryptography package when it converted to Rust. And that's just an example. What about all the projects shipping to embedded systems, tiny Linux distros, specialty proprietary OSs, and so on?

pciexpgpu 4y ago

There needs to be a new PL word for languages that work side-by-side (SxS?) with a legacy language. Not to replace it but coexist peacefully. TypeScript, Kotlin, Swift and even C++ are all great examples of SxS languages. Carbon could be a great SxS language with enough inertia building up over time: still never aim to replace C++ (a fool’s errand) but always work in conjunction with large C++ codebases. It’s such a great pleasure to write things in TS while always being able to use mix-match JS libraries and tooling and debugging. I hope Carbon achieves a similar result moving the industry and engineers forward without resorting to “languages are religions” tediousness.

IOT_Apprentice 4y ago

Dumb question. If you have language servers and AI systems like ChatGPT can’t you train them to rewrite c++ code to a different language? Can’t you also train it to detect pointer errors as well?

doubtfuluser 4y ago

As long as we have articles claiming language xyz replaces C++, c++ will be fine. The day none writes about c++ anymore is when it will be replaced.

mnemotronic 4y ago

C++ has become a feature magnet and punctuation character gumbo. How long before the Carbon language committee decides they need to add "cool" obscure features found in other languages and thereby needlessly complicate it to death.

pjmlp 4y ago
Just wait if generic keywords make into Rust, with ? prefixes.

return_to_monke 4y ago

> Dart is a language on top of JavaScript and other languages with the mission to be the main language for the Flutter project, addressing the creation of cross-platform apps. The JavaScript part is a factual error. Dart can compile to js. Dart can also soon compile to wasm, but most of dart code runs on the dart VM and has nothing to do with JS.

pjmlp 4y ago

Not really, at least not during this decade. > Note that we don't expect to finish the 0.1 language work in 2023. Our goal is to make sufficient progress that we can complete it in 2024, but there are still many things that can go wrong and cause significant delays. https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/roadmap.md https://github.com/carbon-language/carbon-lang/blob/trunk/do... So while an interesting experiment, and it can even get an ecossytem of its own, provided it doesn't go out of steam, it is still quite far from that.

blippage 4y ago

Also worth reading: The Year [2022] of C++ Successor Languages [0] "interface" seems a step forward, amongst other things. I'd like to see Sumtypes (aka Algebraic Data Types) without the pain. And recursive data structures. And co-routines for mortals. I'd be tempted to check out Carbon at some point. I am mistrustful of Google, though, what with their whole telemetry idea in Go. A good outcome would be if Carbon pollinated some ideas into C++, acting as a testbed. I think that C++ has steered itself exceptionally well, actually. It has aimed at stability rather than "move fast and break things". It has avoided the missteps of Raku (Perl 6), Python 3. The fact that people "hate" C++ is on balance more of a feature than a bug. The newer languages have projects which sometimes mandate nightly builds (I'm looking at you, Rust and Zig). It feels that you're trying to build a house on a sandbank. I hope that C++ never gets a package manager/build system. I'm not convinced that they've ever really been done properly or stably (Python seems to have a plethora of install methods, for example), and it leads to the mentality of kitchen-sinking dependencies. [0] https://accu.org/journals/overload/30/172/teodorescu/ https://accu.org/journals/overload/30/172/teodorescu/

lizmat 4y ago
> It has avoided the missteps of Raku (Perl 6) It is unclear to me what missteps you are referring to?
- blippage 4y ago
  It took over a decade to produce. After all that, it was pretty damn slow, and I suspect that many people thought it was too slow to be worth using.
  - lizmat 4y ago
    Well, performance has been improved by several orders of magnitude since the first release. So maybe it's time to look at https://raku.org https://raku.org again (or first have a look at its new documentation site https://docs.raku.org https://docs.raku.org)