www.digitalmars.com         C & C++   DMDScript  

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

reply Carsten Schlote <carsten.schlote gmx.net> writes:
Hi,

today I had to write some unittests for the googletest framework. 
For one of the tests I had to read binary files, and fed their 
contents to some code for testing. In D this is really simple:

```D
import std.file;
auto inbuffer = cast(byte[]) read("MyTestVectorData.bin");
```
In C++ this simple task expands to the following *self-written* 
code:

```C++
     // Lots of includes needed to compile this code
     std::vector<uint8_t> readFile(const char* filename)
     {
         // open the file:
         std::ifstream file(filename, std::ios::binary);
         // Stop eating new lines in binary mode!!!
         file.unsetf(std::ios::skipws);
         // get its size:
         std::streampos fileSize;
         file.seekg(0, std::ios::end);
         fileSize = file.tellg();
         file.seekg(0, std::ios::beg);
         // reserve capacity
         std::vector<uint8_t> vec;
         vec.reserve(fileSize);
         // read the data:
         vec.insert(vec.begin(),
                    std::istream_iterator<uint8_t>(file),
                    std::istream_iterator<uint8_t>());
         return vec;
     }
     /* ... somewhere else below, then and finally ... */
     auto myFilebuffer = readFile("Foo.bin");
```

I have problems to understand, why everything really useful is 
not part of STDL. Or why  is whitespace skipping some default and 
must be unset? Or why is there no simple wrapper to query the 
file size instead of doing old-fashion seek-around? Or ...

So, if you need an example, why C++ simply s***s and D just 
rocks, use this... ;-)

     Regards
       Carsten
Mar 16 2022
next sibling parent reply user1234 <user1234 12.de> writes:
On Wednesday, 16 March 2022 at 09:19:19 UTC, Carsten Schlote 
wrote:

 Hi,

 today I had to write some unittests for the googletest 
 framework. For one of the tests I had to read binary files, and 
 fed their contents to some code for testing. In D this is 
 really simple:

 [...]

 So, if you need an example, why C++ simply s***s and D just 
 rocks, use this... ;-)

     Regards
       Carsten


You're right on the fact that D std is better for that but 
apparently there were shorter c++ alternatives (just searched 
"stdc++ read file in vector")

```C++
std::vector<uint8_t> vec readFile(const char* filename)
{
   std::vector<uint8_t> vec;
   if (FILE *fp = fopen("MyTestVectorData.bin", "r"))
   {
     char buf[1024];
     while (size_t len = fread(buf, 1, sizeof(buf), fp))
     {
       v.insert(vec.end(), buf, buf + len);
     }
     fclose(fp);
   }
   return vec;
}
```

or

```C++
std::vector<uint8_t> readFile(std::string filename)
{
   std::ifstream instream(filename, std::ios::in | 
std::ios::binary);
   std::vector<uint8_t> 
data((std::istreambuf_iterator<char>(instream)),
      std::istreambuf_iterator<char>());
   return data;
}
```
Mar 16 2022
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 16 March 2022 at 11:20:45 UTC, user1234 wrote:

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

 ...


 You're right on the fact that D std is better for that but 
 apparently there were shorter c++ alternatives (just searched 
 "stdc++ read file in vector")


There's also a clear difference in the philosophy of the two 
languages.

D aims a lot to be general purpose, C++ aims to be flexible and 
usable in all areas, even low-level or obscure systems.

Thus D standard library makes a lot of decisions and assumptions 
for the users and locks users within those guidelines mostly.

C++ doesn't make a lot of decisions or assumptions about the 
user, everything is mostly left up to the user to decide how they 
want to do a specific thing.

So if you want total control and freedom, then you'll end up with 
something like what C++ offers anyway.
Mar 16 2022
next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 16 March 2022 at 11:56:33 UTC, bauss wrote:

 D aims a lot to be general purpose, C++ aims to be flexible and 
 usable in all areas, even low-level or obscure systems.

 Thus D standard library makes a lot of decisions and 
 assumptions for the users and locks users within those 
 guidelines mostly.

 C++ doesn't make a lot of decisions or assumptions about the 
 user, everything is mostly left up to the user to decide how 
 they want to do a specific thing.

 So if you want total control and freedom, then you'll end up 
 with something like what C++ offers anyway.


There is nothing stopping C++ from implementing a read function 
similar to D and it can coexist together with the existing 
interface. I think it is some kind of tradition preventing the 
standard library to be user friendly. Many companies use Qt-core 
(despite they don't use any GUI part of it) instead because that 
library is more usable .

Also the idea that std::istreambuf_iterator<char>() is a good 
name for an end iterator further proves that point. There must be 
another better name for it though.
Mar 16 2022
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 16, 2022 at 04:33:30PM +0000, IGotD- via Digitalmars-d wrote:
[...]

 There is nothing stopping C++ from implementing a read function
 similar to D and it can coexist together with the existing interface.
 I think it is some kind of tradition preventing the standard library
 to be user friendly. Many companies use Qt-core (despite they don't
 use any GUI part of it) instead because that library is more usable .

 Also the idea that std::istreambuf_iterator<char>() is a good name for
 an end iterator further proves that point. There must be another
 better name for it though.


A lot of this is historical baggage. C++ was designed back in the days
when user-friendliness was not a big concern (even less so for
programmer-facing interfaces -- programmers were expected to just deal
with it).  Back then, there was also little precedent for what we see
today in, e.g., D's streamlined range API.  Even the idea of traits was
brand new, nobody had experience with it so no one knew what was a good
design or not.  Once the initial APIs were designed, unfortunately, the
naming conventions kinda stuck: newer APIs had to at least be somewhat
similar to previous APIs, in order to keep whatever level of consistency
existed in C++ (which wasn't very much, though, admittedly).  So you
have this inherited poor naming scheme / API style that just keeps
perpetuating.

By today's standards, of course, a lot of this was poor design
decisions. D learned from C++'s mistakes (at least some of it anyway)
and had the benefit of prior art to base design decisions on.  As they
say, hindsight is always 20/20.


T

-- 
Amateurs built the Ark; professionals built the Titanic.
Mar 16 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2022 9:49 AM, H. S. Teoh wrote:

 D learned from C++'s mistakes (at least some of it anyway)


LOL
Mar 17 2022
prev sibling parent reply Carsten Schlote <carsten.schlote gmx.net> writes:
On Wednesday, 16 March 2022 at 11:56:33 UTC, bauss wrote:

 There's also a clear difference in the philosophy of the two 
 languages.

 D aims a lot to be general purpose, C++ aims to be flexible and 
 usable in all areas, even low-level or obscure systems.


In BetterC mode or with GC disabled you can use D for low-level 
as well.


 Thus D standard library makes a lot of decisions and 
 assumptions for the users and locks users within those 
 guidelines mostly.


The phobos library is perfectly tuned to support every-days work, 
D scripts (!) and tools. I use Dlang a lot for scripting and 
build tools. This is more or less impossible in C/C++ as nearly 
everything useful is missing in libc and the stdc++ libraries.


 C++ doesn't make a lot of decisions or assumptions about the 
 user, everything is mostly left up to the user to decide how 
 they want to do a specific thing.


So everyone is reinventing the wheel for even the most simplest 
things. This is surely no advantage.


 So if you want total control and freedom, then you'll end up 
 with something like what C++ offers anyway.


As said, in BetterC mode you can create bare-bine code as well. 
But with most important D language features still available.
Mar 17 2022
next sibling parent bauss <jj_1337 live.dk> writes:
On Thursday, 17 March 2022 at 07:38:52 UTC, Carsten Schlote wrote:

 On Wednesday, 16 March 2022 at 11:56:33 UTC, bauss wrote:

 There's also a clear difference in the philosophy of the two 
 languages.

 D aims a lot to be general purpose, C++ aims to be flexible 
 and usable in all areas, even low-level or obscure systems.


 In BetterC mode or with GC disabled you can use D for low-level 
 as well.


 Thus D standard library makes a lot of decisions and 
 assumptions for the users and locks users within those 
 guidelines mostly.


 The phobos library is perfectly tuned to support every-days 
 work, D scripts (!) and tools. I use Dlang a lot for scripting 
 and build tools. This is more or less impossible in C/C++ as 
 nearly everything useful is missing in libc and the stdc++ 
 libraries.


 C++ doesn't make a lot of decisions or assumptions about the 
 user, everything is mostly left up to the user to decide how 
 they want to do a specific thing.


 So everyone is reinventing the wheel for even the most simplest 
 things. This is surely no advantage.


 So if you want total control and freedom, then you'll end up 
 with something like what C++ offers anyway.


 As said, in BetterC mode you can create bare-bine code as well. 
 But with most important D language features still available.


I'm not siding with C++ lol... I'm just stating why it's 
different.

Obviously I prefer D over C++, otherwise I'd be active elsewhere.
Mar 17 2022
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 March 2022 at 07:38:52 UTC, Carsten Schlote wrote:

 On Wednesday, 16 March 2022 at 11:56:33 UTC, bauss wrote:

 There's also a clear difference in the philosophy of the two 
 languages.

 D aims a lot to be general purpose, C++ aims to be flexible 
 and usable in all areas, even low-level or obscure systems.


 In BetterC mode or with GC disabled you can use D for low-level 
 as well.


Sure, but there are D and C++ have different cultures, and 
actually C++ has multiple cultures (and so does D, even if the 
scale is much smaller).

So in C++ you have the original 80s/90s C++ culture of making C 
more high level, where the somewhat annoying stream concept comes 
from. That abstraction is mostly useful for prototyping (and that 
applies to most of the containers too)… but as computers have 
become more powerful C++ has become less and less sensible for 

TypeScript has eaten into application areas that used to be done 
in C++. When you do lower level programming in C++ you usually 
use the platform APIs and even the C-API is considered too 
abstract and limited. So, what you usually would do is that you 
encapsulate the platform specific code in you application and 
translate that limited platform dependent code to new platforms 
as you expand.

While it is tempting to think that is possible to create a 
portable file API, it actually isn't. The only reason that it 
seems possible is that POSIX has historically been a target for 
common operating systems for personal use. However, when you go 
diskless and use cloud file systems you are in a field where you 
have to do things differently. Which means major rewrites if your 
application assume a conventional file system. That said, the 
"read whole file at once" and "write whole file at once" probably 
is the most portable abstraction, but you also need to deal with 
other aspects of a file system than that (like transactional 
aspect or archiving/journaling features)… so abstractions are 
problematic and their usefulness is limited in time.

In D you have at least two different cultures, those that use D 
as a native higher level language/scripting language and those 
that use D as a C++ replacement. The more expansive standard 
library of D enables more scripting like programming, although 
there are areas where the more limited C++ standard library is 
more complete.

In short, C++ has aimed for minimalistic standard library and D 
has aimed for a Python-like standard library. There are 
advantages and disadvantages in both approaches and what makes 
most sense depends on the usage scenario.
Mar 17 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 16 March 2022 at 11:20:45 UTC, user1234 wrote:

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

 Hi,

 today I had to write some unittests for the googletest 
 framework. For one of the tests I had to read binary files, 
 and fed their contents to some code for testing. In D this is 
 really simple:

 [...]

 So, if you need an example, why C++ simply s***s and D just 
 rocks, use this... ;-)

     Regards
       Carsten


 You're right on the fact that D std is better for that but 
 apparently there were shorter c++ alternatives (just searched 
 "stdc++ read file in vector"


If you can assume that the file isn't modified then use 
std::filesystem::file_size to obtain the size, allocate a buffer 
and use C-api to read the file in one go.
Mar 16 2022
prev sibling parent Carsten Schlote <carsten.schlote gmx.net> writes:
On Wednesday, 16 March 2022 at 11:20:45 UTC, user1234 wrote:

 You're right on the fact that D std is better for that but 
 apparently there were shorter c++ alternatives (just searched 
 "stdc++ read file in vector")


Thanks for the proposals. I used the more C-ish one for my 
cleanup ;-)
Mar 17 2022
prev sibling next sibling parent reply kdevel <kdevel vogtner.de> writes:
On Wednesday, 16 March 2022 at 09:19:19 UTC, Carsten Schlote 
wrote:
[...]

 In D this is really simple:

 ```D
 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?
Mar 17 2022
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 17 March 2022 at 16:56:12 UTC, kdevel wrote:

 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?


Read all data from file descriptor:

```d
File f;
f.fdopen(STDIN_FILENO, "rb");
auto inbuffer = f.byChunk(4096).join;
```
Mar 22 2022
prev sibling parent reply mee6 <mee6 lookat.me> writes:
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.
Mar 19 2022
parent reply bachmeier <no spam.net> writes:
On Saturday, 19 March 2022 at 17:43:16 UTC, mee6 wrote:

 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.


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.
Mar 19 2022
parent reply mee6 <mee6 lookat.me> writes:
On Saturday, 19 March 2022 at 20:05:52 UTC, bachmeier wrote:

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

 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.


 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.


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.
Mar 19 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 19 March 2022 at 23:07:41 UTC, mee6 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.


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.
Mar 20 2022
parent reply bachmeier <no spam.net> writes:
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". 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:


 Well, a language alone doesn't make ecosystems, D is a good 
 language, but after 10 years doesn't hold a candle to CUDA, 
 Metal, Unreal, SYSCL, AUTOSAR/MISRA certifications, 
 iOS/Android/Windows SDK, High Energy Physics research, 
 PyTorch/Tensorflow, LLVM/GCC, ....


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


 D, well it has MIR and vibe.d, that is about it.


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.
Mar 20 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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.
Mar 20 2022
parent bachmeier <no spam.net> writes:
On Sunday, 20 March 2022 at 12:10:50 UTC, Ola Fosheim Grøstad 
wrote:

 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.


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.
Mar 20 2022
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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". 
 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:


 Well, a language alone doesn't make ecosystems, D is a good 
 language, but after 10 years doesn't hold a candle to CUDA, 
 Metal, Unreal, SYSCL, AUTOSAR/MISRA certifications, 
 iOS/Android/Windows SDK, High Energy Physics research, 
 PyTorch/Tensorflow, LLVM/GCC, ....


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


 D, well it has MIR and vibe.d, that is about it.


 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.


I have indeed written a couple of lines in D, in case you are 
interested I have ported a compiler from Java to D, a low level 
memory allocator from C++ to D, and a few OpenGL demos.

Have I ever delivered any D into production?

It would be great, but that isn't what puts bread on the table, 

they are starting to occasionally also ask for Go and Rust 
knowledge as differentiation factor.

My critics of D, that you take so personally, are usually meant 
as a reality check for a language that I follow since Andrei has 
published his book.

All these years people keep comparing D to other languages, while 
in meantime the other languages got most of the features that 
made D innovative a decade ago, with an ecosystem that D will 
never have, yet keeps being ignored when bashing other languages 
for lack of D features.

Be assured I won't be stealing forum threads any more (to use 
your own words), it is clear it is a waste of my time and the 
audience here.
Mar 20 2022
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 20 March 2022 at 13:50:54 UTC, Paulo Pinto wrote:
...

 Be assured I won't be stealing forum threads any more (to use 
 your own words), it is clear it is a waste of my time and the 
 audience here.


I've enjoyed your writing and observations on a number of 
occasions and hope to see more in the future

In line, I believe, with many of your posts I can see a lot of 
good reasons to avoid D at this time: if you are a contractor, or 
work to support/extend a very large code base, or have 
conservative management, or prefer cut and paste development or 
... then D is probably not for you.

OTOH, if you aim to disrupt then D could be a great choice.
Mar 20 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 20 March 2022 at 14:56:45 UTC, Bruce Carneal wrote:

 In line, I believe, with many of your posts I can see a lot of 
 good reasons to avoid D at this time: if you are a contractor, 
 or work to support/extend a very large code base, or have 
 conservative management, or prefer cut and paste development or 
 ... then D is probably not for you.

 OTOH, if you aim to disrupt then D could be a great choice.


I don't think a language has to be commercially viable for 
corporations in order to be interesting to use, but Paolo is spot 
on when it comes to D having lost direction and falling behind…

It is better to just say that competing head-to-head with C++ is 
not a goal than to give the impression that it is while spending 
time on things that doesn't provide any advantages for existing 
C++ programmers (e.g. weird string interpolation etc) and also 
not having a clear plan for reaching parity with C++17. If D ever 
gets there with this lack of focus you'll be up against C++26 
when D has the C++17 features set and you will stil not be able 
to win over C++ programmers.

But is totally fair to create something in a direction completely 
different from where C++ is heading, if that is more interesting 
to the D designers, but then they should forget everything they 
think they know about C++ and create something novel.

In general, there are too many languages now that are 
almost-the-same, so if going head-to-head with C++ isn't 
realistic/fun… then stake out a niche that isn't already filled 
with other languages.

(my personal opinion is that going for per-actor-gc and ARC could 
be interesting enough to create a distance to most other 
languages).
Mar 20 2022
prev sibling parent reply Tejas <notrealemail gmail.com> writes:
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". 
 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:


 Well, a language alone doesn't make ecosystems, D is a good 
 language, but after 10 years doesn't hold a candle to CUDA, 
 Metal, Unreal, SYSCL, AUTOSAR/MISRA certifications, 
 iOS/Android/Windows SDK, High Energy Physics research, 
 PyTorch/Tensorflow, LLVM/GCC, ....


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


 D, well it has MIR and vibe.d, that is about it.


 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.


I think Paulo and others are responding to the underlying 
statement that the OP was trying to say, that D is better than 
C++ and <refer to compile time string example> this is why we 
should prefer D over C++
(Atleast that's what I inferred)

They point out that feature superiority does not compensate for 
the ecosystem fragility(I'm not saying this, that just seems to 
be the sentiment echoed by them)

It's a little frustrating to read, but one can just gloss over if 
they don't want a dose of negativity(or "reality", I guess).
Mar 21 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 21 March 2022 at 13:36:47 UTC, Tejas wrote:

 They point out that feature superiority does not compensate for 
 the ecosystem fragility


You cannot point to individual features (and especially not make 
assumptions about a feature that was added in C++20) and claim 
that it is somehow significant. You have to look at the whole 
package and how the features play together for a specific use 
case. Whether the eco system matters or not also depends on the 
use case (in many C++ scenarios you don't build on many external 
libraries, so that may or may not be significant, depends on the  
context).

You might argue that string mixin is a superior feature. Although 
that feature makes code much less maintainable (read the source 
code for the D standard library and you'll see why), so whether 
you classify that as an advantage or a way to aggregate debt and 
increase costs over the project life-time depends on whether you 
write larger programs that are maintained over a long period of 
time or not.

In the real world language-specific features have little impact 
on application development unless you use them to a large extent. 
Does anyone have a list of usage scenarios for compile time 
strings without string mixins that would motivate a programmer to 
shift to another language to get it? I've never had the need for 
it outside string mixins, so I would argue that how features play 
together typically is more important than any individual feature.

Right now, D lacks basic things that C++ programmers would 
expect, so if you want to sway them to switch over it is rather 
pointless to point at things they rarely need, or that they can 
implement in a few hours, or that is in the pipeline for 
C++23/C++26.

You need to point to a plan for how D is going to address those 
features they feel lacking.

Or, given the stagnation of D, it might be much better to stop 
focusing on C++ and do something completely different from what 
C++ does.
Mar 21 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 21 March 2022 at 15:23:21 UTC, Ola Fosheim Grøstad 
wrote:

 Does anyone have a list of usage scenarios for compile time 
 strings without string mixins that would motivate a programmer 
 to shift to another language to get it?


Stealing a bit of Symmetry Investments prototype code I'm 
currently working on to demonstrate.

```d
template addMonthsStick(DateType) {
      SILdoc("Adds m number of months"
         ~ " to a " ~ __traits(identifier, DateType)
         ~ "[snip the rest of doc description]"
     )
     DateType addMonthsStick(DateType arg, long m) {/*...*/}
}
```

IOW, generating documentation for Symmetry Integration Language 
function at compile time.

Also, https://code.dlang.org/packages/pegged. While it works with 
string mixins, you can also make a separate program to generate 
the parser for your main project. That way you avoid having the 
compiler processing the PEG over and over again at compile time.
Mar 21 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 21 March 2022 at 16:07:44 UTC, Dukc wrote:

 ```d
 template addMonthsStick(DateType) {
      SILdoc("Adds m number of months"
         ~ " to a " ~ __traits(identifier, DateType)
         ~ "[snip the rest of doc description]"
     )
     DateType addMonthsStick(DateType arg, long m) {/*...*/}
 }
 ```

 IOW, generating documentation for Symmetry Integration Language 
 function at compile time.


Ok, so you use it to access reflection within the compiler 
instead of using "compiler as a library".


 Also, https://code.dlang.org/packages/pegged. While it works 
 with string mixins, you can also make a separate program to 
 generate the parser for your main project. That way you avoid 
 having the compiler processing the PEG over and over again at 
 compile time.


Not sure why you would do this as a compile time evaluation if 
you run it separately anyway?

Both these use cases are what I would consider "auxiliary usage" 
and not so much relevant for building libraries IMO, although 
being able to extract information using reflection is nice 
workaround if you don't have access to an "compiler as a library" 
feature.
Mar 21 2022
prev sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 19 March 2022 at 23:07:41 UTC, mee6 wrote:

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

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

 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.


 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.


 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.


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


 You can write that helper function put it in a util file and 
 never have to write it again.


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.
Mar 20 2022
parent mee6 <mee6 lookat.me> writes:
On Sunday, 20 March 2022 at 10:55:49 UTC, bachmeier wrote:

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

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

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

 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.


 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.


 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.


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


Yes I did, the whole paragraph is about the topic. I said the 
example given is something that can be a single function you use 
as a utility. This can be a single header file in C++. Once you 
write the function it can be used again and again. Now C++ isn't 
perfect so you have to write the code yourself but it's a 
relatively simple function to write. On the other hand D has a 
problem with much more difficult problems to write, just like the 
std library is a library, there aren't many third party libraries 
that are of good quality. Including the STD library itself, as it 
too is a library to be criticized. And then I give an example.

All the above information is there just compressed. Sorry I 
inferred a few common knowledge things I thought were common 
knowledge and I ended up writing it in a more compact form.


 You can write that helper function put it in a util file and 
 never have to write it again.


 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.


They are related or are we not talking about a function or 
utility function in a library and we are talking about how one 
library doesn't have that utility function. Now just replace 
utility function with a class instead. It's basically the same 
thing, your just arguing a straw man argument to dismiss the 
criticism instead of just addressing the criticism.
Mar 20 2022