Why is D unpopular?

[Adrian Matoga]

On Thursday, 28 April 2022 at 07:54:44 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 27 April 2022 at 22:43:25 UTC, Adrian Matoga 
> wrote:
>> of like it) at work. I've recently returned to tinkering with 
>> electronics and programming at home so let me share my view.
>
> Do you use or plan to use microcontrollers? If so, with what 
> language?

I do, mostly STM32s. Based on what Adam and Mike's had shared it 
wasn't hard to get started, but lacking a readily usable HAL or 
RTOS was heavily distracting from actual work towards 
constructing some basic framework instead. Still, all the compile 
time stuff D has is very useful in that environment, so is e.g. 
the scope(exit)/scope(failure) feature that makes resource 
cleanup much less confusing without the need to write any 
wrappers.

Currently I'm working on an RPi Hat where I had to add some 
drivers to Linux, where anything other than C won't work, but I 
have the userspace app on top of it, which is all written in D 
and it's way more convenient for me to develop it than e.g. in 
C++, even though I had to manually add a lot of bindings. Plus, I 
have very pleasant experience with GDC on RPi since the very 
moment I got my first Pi around 2013. LDC works very well too, 
but GDC is easier to get OOTB both in native Raspbian and in 
buildroot. Iain's work is a true game changer.


>> technology or even non-technology related idea too. Python 
>> became the default language for ML, because it was easy enough 
>> for people whose main focus wasn't programming, and who didn't 
>> require system level performance because available bindings to 
>> C libraries were good enough.
>
> Yes, but I think this also has something to do with Python 
> replacing Matlab in academic research institutions. Python is 
> becoming the default platform for analysis and experimentation.

Right! I studied CS at physics department and many teachers were 
either nuclear or solid state physicists, so we did a lot of 
Matlab, and Python was only about to enter the field. ROOT was 
also used in some projects but I could never wrap my head around 
its weirdness.

>> What D tried to do was to be "better C++" or "better C", but 
>> in 2022 it's about 40 years too late to be successful in that. 
>> There're millions of programs in C and C++ that have been good 
>> enough to make revenue for many companies and thus convinced 
>> others to invest more money, effort and time in more stuff 
>> that depends on C and C++.
>
> Yes, and they are ISO standards, so nobody "owns" C or C++. 
> That creates a more "open" evolution that is industry-oriented 
> (the main purpose of ISO is to make industrial tools and 
> interfaces interoperable).

Yup, standardization may play a big role in adoption too. We've 
worked with customers who strongly insisted on sticking to OpenCL 
C with no extensions, rather than switching to CUDA or any 
vendor-specific extensions to OCL, both to have clean hands in 
terms of safety and to avoid vendor lock-ins, even though that 
meant worse performance and fatter hardware bills.

>> do something beyond those. I recall I had some good experience 
>> with C# in terms of how quickly I was able to reuse existing 
>> libraries and implement any new code, especially with pretty 
>> convenient tooling from MS, but that was long time ago when it 
>> wasn't seriously usable outside Windows and I didn't have much 
>> interest in developing for Windows later.
>
> What made C# easy to use? Was it auto-completions and 
> suggestions in the IDE, or was it something that has to do with 
> the language itself?

The language itself in the times of D1 was very similar in look 
and feel and expressiveness to D, and they felt equally 
convenient for me. And coming from {} mindset, both were easy for 
me to pick up. However, the VS support for C#, both in 
auto-completions and interactive debug, was mind-blowing. It made 
coding pretty effortless. Nowadays a properly configured IDE for 
C, C++ or D can be just as good in terms of completions.
As for debugging, I've been working for some time in projects 
where languages from python to assembly are mixed with jsons and 
yamls that control various stages of code generation, with 
compilers and even HW specs being still under development, so 
I've learned not to expect anything more than print-, memory 
dump-, logic analyzer- or even guess-based debugging.


>> What I've missed the most so far in D was a zero-effort reuse 
>> of C libraries, because there's a lot of useful libs in C I 
>> already know.
>
> Yes, has the new import-C feature been helpful for you in that 
> regard?

Not yet, as it's not in GDC yet. I expect it to be a huge win for 
system-level headers, like all the ioctls, V4L2, alsa etc. I'd 
really feel safer ABI-wise if they were parsed right from the 
same sysroot as rest of the system.

>> Of course it's much less tedious to interface C in D than in 
>> Python, but I bet if D had a fully-blown ImportC from the very 
>> beginning, it could be where C++ is today.
>
> When compared to C++, I'd say that D still needs to get its 
> memory management story right and fix some language 
> short-coming (incomplete features), but memory management is at 
> least being looked at actively now. (People expect something 
> more than malloc/free and roll-your-own ref-counting.)

Right, C++ has been developing faster for the last decade and got 
much more support from industry, and there are a lot of clever 
freaks working on it. Still many things that should be easy and 
straightforward are being made overly complex, for genericity or 
low-level control or whatever reasons. In that regard I prefer D, 
where I can prototype fast and gradually add lower-level 
optimizations as needed. The latter is also where I find Python 
very cumbersome compared to D.