October 11, 2022

On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

>

On Tuesday, 11 October 2022 at 15:56:11 UTC, Paulo Pinto wrote:

>

...

Currently Swift is not bootstrapped and there is a lot of C++ in the compiler itself. ...

Bootstraping plans are already in motion,

https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524

>

There is currently very little reason to choose C++ over any other modern alternative today for a new project. We will clearly see that as big companies contributions for C++ will wane. Will there even be enough interest to implement C++23?

There are still many domains where for better or worse, C++ rules, and it will for years to come due to ecosystem synergies, see COBOL, Fortran and C. Many tend to forget C is only 10 years younger than COBOL.

However when several big names in the ecosystem start playing with alternatives, we might be at the start of stagnation of the ISO process, but even then, remember many devs keep coding in C89 by choice, and same reasoning can be applied to C++ revisions.

Since we are on D forums, what matters is what piece of the pie D can still get hold of, specially in the mist of stiff competition.

October 12, 2022

On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

>

C++ is starting to become EOL and languages like Swift will take over more and more. Swift is cross platform and available on Linux and Windows.

Swift is much higher level, although there has been some talk of making it more capable for machine-level programming.

Many developers distrust languages like C# and Swift for cross platform, you can basically always expect the support on "foreign platforms" to be subpar and if it isn't you have to plan for platforms being dropped in the future for non-technical reasons.

They may technically be cross platform, but they sure ain't politically cross platform :-).

>

SwiftUI is currently Apple only but if they decide to make it open source

This will not happen with the current culture. Apple is a company that doesn't shy away from patenting and suing over user interface mechanisms and design.

>

There is currently very little reason to choose C++ over any other modern alternative today for a new project.

Objectively speaking, there are plenty of reasons to write performance parts of a new application in C++, if you already know it, as it provides more options than any other competitor. And while C has better interop and portability, C++ still has a wider array of interop and portability options than any other single alternative.

This will remain true until we see a clear sign that other languages are cutting into C++ at scale. Right now they are just nibbling around the edges.

>

We will clearly see that as big companies contributions for C++ will wane. Will there even be enough interest to implement C++23?

Clang seems to be on track with C++23. They are behind on some select features of C++20: https://en.cppreference.com/w/cpp/20

October 12, 2022

On Wednesday, 12 October 2022 at 11:27:26 UTC, Ola Fosheim Grøstad wrote:

>

On Tuesday, 11 October 2022 at 16:14:39 UTC, IGotD- wrote:

>

...

>

There is currently very little reason to choose C++ over any other modern alternative today for a new project.

Objectively speaking, there are plenty of reasons to write performance parts of a new application in C++, if you already know it, as it provides more options than any other competitor. And while C has better interop and portability, C++ still has a wider array of interop and portability options than any other single alternative.

This will remain true until we see a clear sign that other languages are cutting into C++ at scale. Right now they are just nibbling around the edges.

C++ was created for writing distributed systems at AT&T, nowadays other languages rule in across all projects that are part of Cloud Native Computing Foundation, they aren't just a tiny bunch,

https://landscape.cncf.io/

C++ ruled the GUI frameworks tooling during the 1990's, with C++ frameworks being shipped with every compiler, nowadays with exception of Microsoft, there isn't an OS vendor left shipping a C++ GUI framework with the platform SDK. Qt seems to be the last man standing, and even them, had to turn into enterprise customers to keep their developers going.

C++ still has many key domains, when the head of ISO C++ does a public plea for developers to improve C++ instead of going elsewhere, while presenting his own flavour of C++-vnext, one needs to wonder if it will ever be anything past ISO C++26.

Penny and penny laid up will be many.

October 12, 2022

On Wednesday, 12 October 2022 at 11:27:26 UTC, Ola Fosheim Grøstad wrote:

>

Swift is much higher level, although there has been some talk of making it more capable for machine-level programming.

Swift is about just as high level as D, classes come with extra metadata both dynamic and static just like D. Managed pointers (reference types) are ARC so it should be better suited for embedded systems. Unlike D that has @system and unsafe blocks for Rust, for direct access to memory, Swift offers UnsafePointer/UnsafeMutablePointer, UnsafeBufferPointer/UnsafeMutableBufferPointer among others. Certainly an interesting approach, maybe that's the only thing that is needed. Swift does not have @safe/@trusted/@system for foreign functions, you just call them so maybe Walter was right after all.

>

Many developers distrust languages like C# and Swift for cross platform, you can basically always expect the support on "foreign platforms" to be subpar and if it isn't you have to plan for platforms being dropped in the future for non-technical reasons.

They may technically be cross platform, but they sure ain't politically cross platform :-).

Maybe true but that applies for any platform/library. Just look what happened to Qt. In the case of Swift, yes the Linux/Windows implementations lag behind Apple.

October 12, 2022

On Wednesday, 12 October 2022 at 12:24:05 UTC, Paulo Pinto wrote:

>

C++ ruled the GUI frameworks tooling during the 1990's, with C++ frameworks being shipped with every compiler, nowadays with exception of Microsoft, there isn't an OS vendor left shipping a C++ GUI framework with the platform SDK. Qt seems to be the last man standing, and even them, had to turn into enterprise customers to keep their developers going.

Computers get more memory, cores, GPUs and scripting languages with JITs. For most applications it would make more sense to use a JIT for the GUI. Not surprising that the application area shift over time.

But not necessarily for all: C++ is still competitive for audio/video/embedded where you want to build the GUI from the ground up to get a competitive advantage.

>

C++ still has many key domains, when the head of ISO C++ does a public plea for developers to improve C++ instead of going elsewhere, while presenting his own flavour of C++-vnext, one needs to wonder if it will ever be anything past ISO C++26.

LLVM has ensured that there are many other options, so people have more compilers to play with. That means there will be less space for any singular language. The big features like stack-less coroutines isn't really a hobbyist implementation task. There is one big mistake in C++20: they added too many demanding features in one release. It will take years for developers to figure out how to make the best use of coroutines and concepts. C++ need to slow down a bit, they shouldn't add stuff faster than programmers can establish best practices, the result will be chaos.

October 12, 2022

On Wednesday, 12 October 2022 at 12:41:44 UTC, IGotD- wrote:

>

Certainly an interesting approach, maybe that's the only thing that is needed. Swift does not have @safe/@trusted/@system for foreign functions, you just call them so maybe Walter was right after all.

It might be the only thing people need for writing regular apps with a bit of oomph here and there, but the people that use C for signal processing etc are less likely to look at Swift as a replacement.

D has some high level features too, but does not evolve in that direction? It is evolving in the direction of C, it seems.

>

Maybe true but that applies for any platform/library. Just look what happened to Qt. In the case of Swift, yes the Linux/Windows implementations lag behind Apple.

Yes, the Qt case is interesting as it tells us that GPL isn't enough when you need a big budget to drive the evolution of a library.

So maybe the open source community should find some structural way to have many independent parts that interoperate. You basically need a set of open source protocol definitions, with language support, that people can attach their efforts to rather than being a tiny contributor to a gigantic structure.

The current open source community have these monoliths that are clogging up the pipelines when they become too large to change without a commercial entity behind it.

Some "distributed" innovation is certainly needed.

October 12, 2022

On Tuesday, 11 October 2022 at 15:56:11 UTC, Paulo Pinto wrote:

>

On Tuesday, 11 October 2022 at 14:49:44 UTC, Tejas wrote:

>

[...]

clang is good enough for their purposes, Metal Shading Language is a C++14 dialect, IO Kit uses a Embedded C++ dialect and C++17 is good enough for DriverKit and is the current baseline for LLVM contributions.

[...]

But C++20 introduced modules, which will massively reduce build times

Is that feature alone not enough to get up to C++20? It's such a fundamental change

October 12, 2022

On Wednesday, 12 October 2022 at 12:55:25 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 12 October 2022 at 12:24:05 UTC, Paulo Pinto wrote:

>

C++ ruled the GUI frameworks tooling during the 1990's, with C++ frameworks being shipped with every compiler, nowadays with exception of Microsoft, there isn't an OS vendor left shipping a C++ GUI framework with the platform SDK. Qt seems to be the last man standing, and even them, had to turn into enterprise customers to keep their developers going.

Computers get more memory, cores, GPUs and scripting languages with JITs. For most applications it would make more sense to use a JIT for the GUI. Not surprising that the application area shift over time.

That's BS, and i am glad you are not the one responsible of making the iPhone i use

Look at Android, you need 2x the amount of power and ram than an iPhone for similar workloads

Nobody use computers anymore, except some nerds like us

People use resource constrained devices that runs with a battery

JIT is forbidden in games because it introduce stutters

It is forbidden in iOS because it drains the battery and it is a security nightmare

And as the games becomes more resource intensive and the gameplay loop shorter and shorter due to the popularity of high refresh rate screens, nobody will want a language that's slow with a JIT and a poor man's GC

The GC is debatable as we get more cores we can offload the GC work, but GC's like one D has is a handicap nobody wants, both Unity/Unreal offer a concurrent/generational one

It's no wonder D fails to grow, wrong analysis and wrong expectations

What the new popular languages promote? and why they gain popularity?

Why people want to comeup with BetterC++ and not use what's already available

If we keep being delusional, we'll loose everything, and we'll die due to demography, who's gonna left to keep make the D?

D can't be javascript, java, c#, c, c++, rust, zig, typescript, lua, python, swift, nim, pascal all at once, what people say about this kind of thing? "Jack of all trades, master of none"?

October 12, 2022

On Wednesday, 12 October 2022 at 14:52:26 UTC, Tejas wrote:

>

But C++20 introduced modules, which will massively reduce build times

Is that feature alone not enough to get up to C++20? It's such a fundamental change

It might be, but I think only Microsoft has a complete implementation?

Regardless, C++20 "concepts" is basically syntax sugar, but it makes it so much less tedious to write generic code that it is a game changer in my view. If you want to write generic code that is (C++ code is often limited in terms of generic programming).

C++20 coroutines can potentially change the structuring of programs to such an extent at it might create "a new language" if used extensively, but I don't think many know how to make use of those yet, so the potential impact is difficult to judge.

Anyway, there is no shortage of new projects. Here is the number of new Github projects over the past two months:

language number of new projects
C++ 133K
C 90K
Rust 24K
Zig 0.4K
D 0.2K

Nearly an order of magnitude more new projects for C/C++ than Rust. Granted, getting within 10%, for Rust, is pretty impressive.

If we look at what the most starred new projects are used for we get:

  • C++: wasm runtime, audible feedback app, a compiler-compiler, physics module, remote loader, database, firewall workaround, etc

  • Rust: tls, crypto-bot strategy, a javascript jit hack, drag and drop utility for GTK, sqlite filesystem, postgressql monitor, crypto currency tool, package manager improvement, text based ui library

  • Zig: parsing project, bindings for opencv, ssl for wasm, webgpu library, validation library, protobuf library, binding for tensorflow, midi synth, coff file dump

  • D: ui library, xml dom library, library for interfacing with xdg, cell-based text interface, a D library, config file library, math library, D sorting tool, pack/unpack tool, gameboy emulator (work in progress)

So there is a notable difference in what kind of projects we get as the most popular ones. If we compare Rust with C++ we see that the Rust ones are more geared towards tooling, crypto etc. I didn't go beyond the first page, though.

If we look at Zig then we see that it is mostly about building up the Zig eco system. For D we also get some of the same, basically libraries.

The volumes for Zig and D are low, so the results could be more random than the ones for Rust.

October 12, 2022

On Wednesday, 12 October 2022 at 15:21:07 UTC, ryuukk_ wrote:

>

That's BS, and i am glad you are not the one responsible of making the iPhone i use

No need to get personal. Paulo stated a fact, C++ was more central to GUI development in the 90s than today. I stated a fact, more UIs are done using higher level approaches as current hardware ha substantial more resources than in the 90s. That is true for mobiles too. Many mobile apps on iPhone use Dart or JavaScript, so it is clearly present.

>

refresh rate screens, nobody will want a language that's slow with a JIT and a poor man's GC

Dart.
JavaScript.