On Wednesday, 20 July 2022 at 18:15:22 UTC, ryuukk_ wrote:

What is a needed is a plan with dependencies mapped out and priorities assigned, and focused process, but the D evolution history is more impulse driven and the planning aspect has been vague… this is the most limiting factor at this point.

In contrast Carbon has one, and primarily one, huge advantage: they have a big internal business critical use case in Google that will drive new features and tooling. Management will get resources allocated to improve on the weak language spots as they start to use Carbon internally (features driven by internal demand). As such the evolution cannot follow impulses, but has to be driven by plans (which will ensure steady progress).

It remains to be seen whether Carbon will be useful for small projects or end up like Ada: too tedious to be used for small and medium sized projects?

It is very difficult to tell at this point, but there is some arrogance in claiming to be a "C++ successor" at V0.1 and then push a somewhat flawed ML/Rust/TypeScript mashup syntax and less flexible semantics than C++.

One big future problem for D is that Carbon has this huge internal use case and most likely will get solid open source tooling funded by Google and a bunch of tutorials written by self-promoting bloggers.

Today we have the situation that people look at C++, finds it overwhelming, looks at Rust, finds it difficult to get into, then looks at niche alternatives (Zig, D etc). With 3 major system level languages I think many devs will stop looking further when they have looked at the three major contenders and just pick the one they find easier to deal with.

This might be a good time to consider a D3 move.

On Wednesday, 20 July 2022 at 18:15:22 UTC, ryuukk_ wrote:

What is a needed is a plan with dependencies mapped out and priorities assigned, and focused process, but the D evolution history is more impulse driven and the planning aspect has been vague… this is the most limiting factor at this point.

In contrast Carbon has one, and primarily one, huge advantage: they have a big internal business critical use case in Google that will drive new features and tooling. Management will get resources allocated to improve on the weak language spots as they start to use Carbon internally (features driven by internal demand). As such the evolution cannot follow impulses, but has to be driven by plans (which will ensure steady progress).

It remains to be seen whether Carbon will be useful for small projects or end up like Ada: too tedious to be used for small and medium sized projects?

It is very difficult to tell at this point, but there is some arrogance in claiming to be a "C++ successor" at V0.1 and then push a somewhat flawed ML/Rust/TypeScript mashup syntax and less flexible semantics than C++.

One big future problem for D is that Carbon has this huge internal use case and most likely will get solid open source tooling funded by Google and a bunch of tutorials written by self-promoting bloggers.

Today we have the situation that people look at C++, finds it overwhelming, looks at Rust, finds it difficult to get into, then looks at niche alternatives (Zig, D etc). With 3 major system level languages I think many devs will stop looking further when they have looked at the three major contenders and just pick the one they find easier to deal with.

This might be a good time to consider a D3 move.

On Thursday, 21 July 2022 at 11:00:11 UTC, Ola Fosheim Grøstad wrote:

The arrogance can be explained by being the same people that lost the C++ ABI vote at ISO, and since then ramped down their involvement either at ISO or clang further development.

https://old.reddit.com/r/programming/comments/w2thvo/carbon_an_experimental_c_successor_language/igs25eu/

and also https://cor3ntin.github.io/posts/abi/

This is one of the reasons why clang is now third in ISO C++ support, and since no other compiler vendor that enjoys clang, seems willing to step into Apple (focused on Swift/Objective-C) or Google's previous roles, it doesn't look like it will change.

Meanwhile those previous clang contributors are now having fun tailoring Carbon as they wish instead of fighting for their papers at ISO.

This is one of the reasons why clang is now third in ISO C++ support, and since no other compiler vendor that enjoys clang, seems willing to step into Apple (focused on Swift/Objective-C) or Google's previous roles, it doesn't look like it will change.

Meanwhile those previous clang contributors are now having fun tailoring Carbon as they wish instead of fighting for their papers at ISO.

On Friday, 22 July 2022 at 05:39:22 UTC, Paulo Pinto wrote:

Apple tutorials use Objective-C++, but I think they view it as a support language for Swift.

Maybe GPL is the better license for programming languages... gcc could benefit from clang being wiped out.

But they are not very good at it... They are going to end up with some of D’s problems. They need an external qualified reviewer.

Also only support for C++17 as a stated goal does not make you a C++ successor outside of big business legacy code bases.

Which tutorials?

Here is the thing, if the large majority of C++ world never moves beyond C++17, with cherry picked features from later standards, does it really matter?

A paper standard only matter as much as there are actually compilers supporting it.

On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

Performance oriented ones, such as GPU-compute with Metal.

Perhaps not for legacy corporate codebases, but for people who have more recent code bases it probably will.

It matters because stack-less coroutines is a significant feature, by the time Carbon is ready with tooling (say in 5 years) frameworks will have adopted stack-less and people will look forward to C++26. That most likely includes HPC stuff.

MSVC and GCC are heavy weights, and most Clang extensions are close to GCC, so switching a codebase from Clang to GCC isn't really a big deal (or shouldn't be for reasonable code bases).

On Friday, 22 July 2022 at 08:10:49 UTC, Paulo Pinto wrote:

Performance oriented ones, such as GPU-compute with Metal.

Perhaps not for legacy corporate codebases, but for people who have more recent code bases it probably will.

It matters because stack-less coroutines is a significant feature, by the time Carbon is ready with tooling (say in 5 years) frameworks will have adopted stack-less and people will look forward to C++26. That most likely includes HPC stuff.

MSVC and GCC are heavy weights, and most Clang extensions are close to GCC, so switching a codebase from Clang to GCC isn't really a big deal (or shouldn't be for reasonable code bases).

On Friday, 22 July 2022 at 08:42:40 UTC, Ola Fosheim Grøstad wrote:

The more recent ones make use of Objective-C runtime API called directly from C++,

MSVC only matters for Windows and XBox developers, and the new push is most likely triggered from WinDev and XBox business units not being .NET fans, contrary to what is happening at Azure, where .NET, Go, Java and Rust rule the party.

So that leaves GCC, and how much Red-Hat/IBM care to keep it up to date post ISO C++20.

On Friday, 22 July 2022 at 09:47:57 UTC, Paulo Pinto wrote:

Yes, you are right, they use Objective-C in the tutorials, not Objective-C++.

They seem to have added C++ support to their package manager fairly recently:
https://github.com/apple/swift-evolution/blob/main/proposals/0181-package-manager-cpp-language-version.md

I don't quite see Apple adopting Carbon… but who knows?

The ISO process will not move faster than GCC/MSVC, so in that case it means that the evolution will slow down. Which is not a bad thing at this point. The most glaring missing piece in C++ is standardized SIMD support, which is easy to add.

Library only extensions are not going to be a problem for GCC.