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.