On Wednesday, 16 March 2022 at 09:19:19 UTC, Carsten Schlote wrote:
[...]

import std.file;
auto inbuffer = cast(byte[]) read("MyTestVectorData.bin");

What if the program has got an already open socket (int) s or an open File f. How easily are the remaining bytes "slurped" in those cases?

This just boils down to the standard libraries and what they implement. You can write that helper function put it in a util file and never have to write it again. D is considerably lacking when it comes to robust third party libraries. C++ has so many good libraries in comparison. For D you pretty much have to roll your own implementation for everything else. There isn't even basic @nogc containers, so there's a lot you end up having to write yourself. The allocators are experimental, not sure how long it's been now. So there isn't a design philosophy to follow, you'd be making it from the ground up and that's a lot more work than a simple utility function. It feels like it's just left unsolved, it feels that way for D a lot.

On Saturday, 19 March 2022 at 17:43:16 UTC, mee6 wrote:

Excellent example of the off-topic vandalism of discussions I wrote about the other day. It always happens as soon as someone attempts to say something good about D.

Your response has nothing to do with the post. If I were in charge, I would delete it and ban you from posting here again. Not sure if this is an organized effort, but troll posts like this get tiring.

On Saturday, 19 March 2022 at 20:05:52 UTC, bachmeier wrote:

It's not off topic, your post is completely off topic ironically though. A comparison was made and I elaborated on that comparison. It seems you don't like it cause I was being critical of D.

On Saturday, 19 March 2022 at 23:07:41 UTC, mee6 wrote:

Indeed, C++ doesn’t have any scripting like features, D has plenty. However, the typical use cases for C++ involve months or years of development so the time spent collecting and writing utility functions is a drop in the bucket. C++ is not a good choice for people looking for a glorified scripting language though. In that case D or Python + C is more suitable.

Sadly, claims about other languages in the forums tend to be click-baity and specifically for C++ people, who claim to have experience with it, frequently show high levels of ignorance, maybe because they never went past an outdated subset of the language or don’t understand the application area. This is makes for cult like responses where blissful ignorance is celebrated.

If people compare with other languages they should welcome nuances and push back.

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?

The D community’s obsession with C++ does not seem healthy and too much of that can only lead to stagnation/apathy, D needs to tear itself away from all that and choose its own unique path.

On Saturday, 19 March 2022 at 23:07:41 UTC, mee6 wrote:

You didn't engage at all with the topic of the post. You dismissed it with one sentence:

Then you went on to talk about something else, in an attempt to change the topic completely - something that's the case with 100% of these posts. Either engage with the post, start your own thread, or post somewhere else. That's the way they do it most places on the internet.

On Sunday, 20 March 2022 at 07:55:51 UTC, Ola Fosheim Grøstad wrote:

Nonsense. Someone created a thread titled "The problem that took him 5 years to fix in C++, I solved in a minute with D". Paulo Pinto, who may or may not have written a line of D code used in production at some point in the last 20 years, responded with this:

Not only did he not respond to the post, he completely ignored it to talk about something unrelated. Then he later posted this:

That's obviously wrong, but ultimately he succeeded at his goal of changing the discussion. And he did it without even pretending to engage with the original post.

On Sunday, 20 March 2022 at 11:11:03 UTC, bachmeier wrote:

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.

On Sunday, 20 March 2022 at 12:10:50 UTC, Ola Fosheim Grøstad wrote:

Interesting that you can't bring yourself to admit that the discussion I quoted was off-topic. The person I quoted should have commented on the post if it was wrong. They didn't.