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++".
> And C++ just... doesn't have that many real problems.
It does not have many, but it has one and it's big. It's not memory safe.
Check out this talk by Herb Sutter, around minute 43:
This is the first time a government [see note] has actually issued guidance to industry broadly that was the barest paraphrase away from "where possible don't use C and C++"
[ Note: in this context, the "government" is the US Department of Commerce and NIST, which, according to Herb, have issued a detailed guidance in response to the Executive Order on Cybersecurity [2]. While I couldn't find that guidance, I found one by the NSA [3], which saw quite a few comments here on HN in December last year [4] ].
> And C++ just... doesn't have that many real problems.
From Carbon's README:
> C++ [...] is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.
> And C++ just... doesn't have that many real problems.
I can honestly say I've never known anyone who has written a lot of code in both C++ and some other language who has this opinion. I'd say, to the contrary, that almost every feature and characteristic of C++ is a problem - it's either a complete disaster in terms of programmer ergonomics or it makes it way too easy to create terrible bugs. It's _all_ wrong.
> So based on the article's own observation: no, of course not.
This had very little to the discussion. Of course it can't be replaced. Code is created by humans, and as long as we have opinions nothing gets truly replaced. Just decreased usage over time.
> C++ and Switft just became "more dominant".
Yup, like this. Of course a general statement is no.
I have very little interest in this topic. But I seen this SAME comment a million times on anything thats new that attempts to challenge something. And as usual whether something "dethrones" something is less interesting than what changes or ideas that it offers.
Just like ALL those you listed, they didn't replace any of those, but they definitely challenged the ecosystems, or improved the old ones.
Naunce discussion is far more interesting.
For example, why do you think Carbon won't be able to gain dominance over time? I mean I think thats a huge hurdle too.
Of course, I agree that C++ isn't going to entirely disappear, but I don't understand what you mean by "C++ doesn't have many real problems, only irks". Surely the lack of memory safety is more than a mere irk--certainly Mozilla felt strongly enough to develop an entirely new programming language (as did Carbon's developers), and of course entire domains have moved away from C++ entirely (often in favor of GC languages). Yes, there remains some contingent of people for whom things like "deterministic memory management" or "immaturity for $domain" are bigger problems than those presented by C++, but that doesn't mean that C++ is without real problems, right?
Your definition of "replace" is too strict: the idea of a successor language is not replacing all existing code, but rather making it possible for individual projects to painlessly evolve from the old language to a new one. Some old code - whether entire inactive projects or inactive parts of active projects - may never get rewritten in the new language and that is OK.
Give it time. Unlike the other examples one company (Apple) has full control here. There is basically zero demand for Objective-C outside of development for Apple platforms.
Apple is already making Swift only features and APIs and is deprecating older things. Obj-C is arguably legacy already, but still works fine.
I’ll bet plenty of money there will find a day when Apple says “This is it, next release it’s out of the toolchain”.
Existing developers often have Obj-C code (I do), but the biggest user is Apple. So they can’t kill it tomorrow. But its days are numbered.
No one is in that kind of position with C/C++/JS/Java.
> And C++ just... doesn't have that many real problems.
70% of security bugs are memory safety issues.
That's a lot of 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.
People run into memory safety issues more often in new C++ code.
no language is ever going to be 100% replaced, but C++ has largely replaced C and Swift will likely largely replace Objective-C. this article obviously isn’t discussing whether something will wipe C++ off the face of the earth but that it might replace most of its use cases. why are you nitpicking over the word replace?
Be careful with that, because it only takes government to decide to heavily tax something or simply phase out something for it to go away. Eventually the minority cost rises so it becomes a self full-filling prophecy.
That, will not apply to C++ or languages in general.
Worse still in this enumeration, TypeScript isn't a replacement like the others at all: no major js platform (browsers, nodejs) supports it. (here the term "native support" is thrown around a lot, but I feel at this point you're already well in llvm territory with the definition of "support")
I'd argue Swift has replaced Objective-C, for new code. Or will soon. If Carbon does the same vis-a-vis C++, I'd say they've succeeded in "replacing C++".
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.
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.
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.
Yeah, he tries to sell cpp2 as being different to the other alternatives, due to his position at ISO, however it is just the same thing being an alternative language, compiling via C++ translation doesn't change that.
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.
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.
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.
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.
It's very opinionated and SerenityOS-focused, but the language Jakt ( https://github.com/SerenityOS/jakt ) transpiles to C++, has memory safety and some very neat ideas for readability.
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.
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.
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.
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?
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.
In the context of a language that needs to coexist with C++ codebases, it is a weird decision.
However, Carbon's syntax makes technical sense, and is in line with many contemporary languages (Rust, TypeScript, Swift, Kotlin). It is easier to parse, which is important for tooling and IDEs. `fn name` is easy to grep for. `let` works well with type inference and destructuring assignment, which are becoming standard features in modern languages (although Carbon still supports C-style aggregate initializers, which is not so great).
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.
> 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.
> 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.
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.
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.
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.
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.
[+] [-] TheRealPomax|3 years ago|reply
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++".
[+] [-] credit_guy|3 years ago|reply
It does not have many, but it has one and it's big. It's not memory safe.
Check out this talk by Herb Sutter, around minute 43:
[ Note: in this context, the "government" is the US Department of Commerce and NIST, which, according to Herb, have issued a detailed guidance in response to the Executive Order on Cybersecurity [2]. While I couldn't find that guidance, I found one by the NSA [3], which saw quite a few comments here on HN in December last year [4] ].[1] https://www.youtube.com/watch?v=ELeZAKCN4tY
[2] https://www.whitehouse.gov/briefing-room/presidential-action...
[3] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
[4] https://news.ycombinator.com/item?id=33560227
[+] [-] pizza234|3 years ago|reply
From Carbon's README:
> C++ [...] is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.
[+] [-] mikebenfield|3 years ago|reply
I can honestly say I've never known anyone who has written a lot of code in both C++ and some other language who has this opinion. I'd say, to the contrary, that almost every feature and characteristic of C++ is a problem - it's either a complete disaster in terms of programmer ergonomics or it makes it way too easy to create terrible bugs. It's _all_ wrong.
[+] [-] kalcode|3 years ago|reply
This had very little to the discussion. Of course it can't be replaced. Code is created by humans, and as long as we have opinions nothing gets truly replaced. Just decreased usage over time.
> C++ and Switft just became "more dominant".
Yup, like this. Of course a general statement is no.
I have very little interest in this topic. But I seen this SAME comment a million times on anything thats new that attempts to challenge something. And as usual whether something "dethrones" something is less interesting than what changes or ideas that it offers.
Just like ALL those you listed, they didn't replace any of those, but they definitely challenged the ecosystems, or improved the old ones.
Naunce discussion is far more interesting.
For example, why do you think Carbon won't be able to gain dominance over time? I mean I think thats a huge hurdle too.
[+] [-] throwaway894345|3 years ago|reply
[+] [-] xiaq|3 years ago|reply
[+] [-] MBCook|3 years ago|reply
Give it time. Unlike the other examples one company (Apple) has full control here. There is basically zero demand for Objective-C outside of development for Apple platforms.
Apple is already making Swift only features and APIs and is deprecating older things. Obj-C is arguably legacy already, but still works fine.
I’ll bet plenty of money there will find a day when Apple says “This is it, next release it’s out of the toolchain”.
Existing developers often have Obj-C code (I do), but the biggest user is Apple. So they can’t kill it tomorrow. But its days are numbered.
No one is in that kind of position with C/C++/JS/Java.
[+] [-] hulitu|3 years ago|reply
As "Unix haters handbook" says: C++ is to C, what lung cancer is to lung.
[+] [-] jameswryan|3 years ago|reply
70% of security bugs are memory safety issues. That's a lot of 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.
People run into memory safety issues more often in new C++ code.
https://www.chromium.org/Home/chromium-security/memory-safet...
https://security.googleblog.com/2021/09/an-update-on-memory-...
https://github.com/microsoft/MSRC-Security-Research/blob/mas...
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20pre...
https://advocacy.consumerreports.org/research/report-future-...
https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
https://github.com/google/sanitizers/blob/master/hwaddress-s...
https://security.googleblog.com/2022/12/memory-safe-language...
[+] [-] permo-w|3 years ago|reply
[+] [-] keyle|3 years ago|reply
Be careful with that, because it only takes government to decide to heavily tax something or simply phase out something for it to go away. Eventually the minority cost rises so it becomes a self full-filling prophecy.
That, will not apply to C++ or languages in general.
[+] [-] IshKebab|3 years ago|reply
[+] [-] rf15|3 years ago|reply
[+] [-] nielsbot|3 years ago|reply
[+] [-] JustBreath|3 years ago|reply
[+] [-] taraharris|3 years ago|reply
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
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
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.
[+] [-] Animats|3 years ago|reply
Non-intelligent converters just make a mess. Here's c2rust.[1]
Classic C++ to modern C++, plus a compiler flag to lock out all the old unsafe stuff, would be an achievement.
[1] https://c2rust.com/
[+] [-] lanza|3 years ago|reply
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.
[+] [-] pjmlp|3 years ago|reply
[+] [-] danpalmer|3 years ago|reply
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|3 years ago|reply
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++.
[+] [-] hot_gril|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] SleepyMyroslav|3 years ago|reply
[+] [-] i-use-nixos-btw|3 years ago|reply
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.
[+] [-] coderjames|3 years ago|reply
You're looking for Herb Sutter's CppFront: https://github.com/hsutter/cppfront
As Cfront was to C, Cppfront is to C++.
[+] [-] rjh29|3 years ago|reply
[+] [-] blippage|3 years ago|reply
"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/
[+] [-] lizmat|3 years ago|reply
It is unclear to me what missteps you are referring to?
[+] [-] asow92|3 years ago|reply
Isn't Dart a compiled language that can be compiled to JS via dart2js and not "on top of JavaScript"?
[+] [-] doodlesdev|3 years ago|reply
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/
[1]: https://github.com/angulardart
[2]: https://dart.dev/overview#platform
[+] [-] giancarlostoro|3 years ago|reply
[+] [-] synergy20|3 years ago|reply
[+] [-] Animats|3 years ago|reply
[+] [-] ape4|3 years ago|reply
[+] [-] martin1975|3 years ago|reply
Google could focus on making C++/Rust interop as smooth as Carbon's instead.
[+] [-] vasilipupkin|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] pornel|3 years ago|reply
However, Carbon's syntax makes technical sense, and is in line with many contemporary languages (Rust, TypeScript, Swift, Kotlin). It is easier to parse, which is important for tooling and IDEs. `fn name` is easy to grep for. `let` works well with type inference and destructuring assignment, which are becoming standard features in modern languages (although Carbon still supports C-style aggregate initializers, which is not so great).
[+] [-] pjmlp|3 years ago|reply
The only that really has a chance.
[+] [-] zwieback|3 years ago|reply
[+] [-] pciexpgpu|3 years ago|reply
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.
[+] [-] pjmlp|3 years ago|reply
> 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/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.
[+] [-] return_to_monke|3 years ago|reply
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.
[+] [-] MathMonkeyMan|3 years ago|reply
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.
[+] [-] staunton|3 years ago|reply
[+] [-] andsoitis|3 years ago|reply
[+] [-] andrewstuart|3 years ago|reply
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.
[+] [-] doubtfuluser|3 years ago|reply