Just an example, why D rocks, and C++ s***s...

[Ola Fosheim Grøstad]

On Sunday, 20 March 2022 at 11:11:03 UTC, bachmeier wrote:
> On Sunday, 20 March 2022 at 07:55:51 UTC, Ola Fosheim Grøstad 
> wrote:
>
>> The other thread bachmeier referenced was particularly 
>> misleading for people who lack insight into how C++ is being 
>> used and how it evolves. When people complain about having the 
>> foundational underlying differences explained to them... you 
>> have to wonder if they themselves are insecure about their own 
>> choice, why would one otherwise care so much about C++? And 
>> why would one complain about having practical productivity 
>> concerns being expanded on?
>
> Nonsense. Someone created a thread titled "The problem that 
> took him 5 years to fix in C++, I solved in a minute with D".

I can only speak for myself, and I find it annoying that people 
make all kinds of claims about other languages they have a poor 
understanding of. C++ has compile time strings and dynamic arrays 
as of C++20, and any deficiencies have to be addressed after they 
collect experiences with it, so C++23/26. This is not a topic 
worthy of a thread in a D forum, this is esoteric even in a C++ 
discussion. D need focus on completing existing features, 
streamlining syntax and making the current API/runtime more 
portable.

The D designers seem to have given up on getting competitive with 
the C++ feature set and have instead spent one year on other 
features like "import-C". Ok, fair enough, but then one should 
stop talking about competing with C++, and go for something 
unique. Continuing to focus on C++ seems to be more and more of a 
distraction, as you have to be highly motivated and focused to go 
there. And, the motivation seems to be absent, that is the only 
explanation for D not having gone all in for competitive RAII in 
a timely manner. It is impossible to compete with the C++ feature 
set by tip-toping around like this, so the best strategy now is 
to drop the idea of D being a C++ replacement and choose a 
direction that the designers actually find motivating to work on.

Regarding this thread, it might have been an advantage for D to 
have a "load whole file" API if it was abstract and generic 
enough to work with cloud solutions. The current design is not 
portable enough to be an advantage, but a generic interface that 
would make code truly portable could be a great advantage now 
that cloud support is a big factor in decision making processes.

I've ported a code base to a cloud solution that made file system 
assumptions and  it was very tedious!! These days it is not good 
for a library to make file system assumptions as you then have to 
set up a RAM-based file system to get around that weakness on a 
disk-less server (where RAM is the most expensive resource). 
Getting rid of such plundering issues and create an eco system 
that is highly portable (also for cloud and web-assembly) would 
be valuable, but it takes more than a simple utility function.

So, the idea is right, but the execution needs to be more 
portable for this to be a language advantage.