Why is D unpopular?

[arco]

On Monday, 8 November 2021 at 05:20:43 UTC, harakim wrote:


> I have experienced this phenomenon a lot in my career, but I 
> think D is pretty good at having more than one way of doing 
> things. I like not having to have classes, but I like having 
> them available. The way I feel about frameworks is how I feel 
> about languages like python. You have to do it their way even 
> though you know a better way. With D, I feel like a library. I 
> can use it's features if I want and not if I don't. This is one 
> of it's strongest advantages. If I want to do string handling 
> in a pointer-based way, I can! If I want to use normal methods, 
> the language supports that. Arrays are a great example. You get 
> most of, if not all of, the power of a list in another 
> language, but you get all the power of arrays. I'd like to see 
> an example that shows you get the worst of both! I have relied 
> on that heavily this weekend.

This is great if you are an enthusiast who implements stuff this 
week-end. In large scale projects you unavoidably end up in the 
situation where you are convinced you know a better solution, and 
so does your colleague, and another colleague etc. Of course, 
each of you has a different solution and you all "know" that 
yours is the best. The bicycle sched fallacy is always lurking at 
every corner with this type of approach.

The examples to support my point are plenty. The GC to begin 
with. D relies on a GC so it's not really usable as a systems 
language. At the same time, since it doesn't want to fully commit 
to the GC and wear it with pride, it has a mediocre one and is 
not a good choice for projects where I feel that a GC-based 
language is the way to go. Developers are permanently wondering 
what kind of memory management they should use, because they 
can't see a clear picture or consensus and whichever decision 
they make, it will unavoidably clash with other parts of the 
ecosystem or even the same codebase.

Similarly you may want to handle your strings as pointers like in 
C, but Joe's output library expects std.string. What now? As a 
result, the developer spends time dealing with trivial issues 
like that instead on focusing on solving the actual problem.

It just keeps coming back to the same issue: the point of 
software development is not to have fun with the language or be 
"creative" with it, it's to provide a solution to a problem that 
other people will be able to use with as little friction as 
possible.

> Although I agree with pretty much everything you have written, 
> I think that is one of D's strengths. That was reiterated this 
> weekend. I got a call for a job and they said the next 
> interview would be on codesignal.com. I did about 100 practice 
> problems and I found myself reaching for D a lot. There were 
> some problems where I pretty much had to go to C# if I wanted 
> to do it in under 5 minutes (most things Linq related or string 
> related. I don't know what D's equivalents are.)

You know D, you like D so it's natural that you would often reach 
for D to solve a problem. But the point of this thread is not 
that people who appreciate D can use it to do things, it's why 
the other people are not showing more interest in D.

>
> I don't think D needs to stick to one way to do everything. I 
> think Python is popular almost in spite of it's one-way-only 
> philosophy because it's easy to start and it has good 
> libraries. (Although being easy to get started is probably 
> helped by the one-way-only philosophy for reasons I get to 
> below.) You get that constant success feedback where you write 
> something and it works right away. Then you tweak it and get 
> little wins along the way. D is similar except for some safety 
> stuff that I have ideas about (immutable, const, etc.)

I think the fact that Python lives by its "one true way only" 
philosophy is precisely the reason it is so easy to get started 
with and has such good libraries. It's easy because tutorials 
make sense, if you are beginning and face a problem, other people 
can help you easily, and libraries provide APIs with little or no 
surprise and for the overwhelming part, they work well together. 
Perl, in contrast, said "there shall be more than one way to do 
it". Its ecosystem has always been a huge mess.

Now of course D doesn't need to stick to one way for absolutely 
everything, otherwise it would be a DSL which is obviously not 
its purpose. But it should at least have a clear and cogent 
memory management story (and not "you can do it absolutely every 
way you want and so can everyone else"). It should have a clear 
position on strings. Autodecoding was a bad idea and maybe it's 
now stuck with it, or maybe it's possible to introduce a new 
string type that doesn't autodecode and keep std.string for 
legacy code, but there should be The D Way of handling strings 
(and not "ok and you can also use pointers like in C, and by the 
way you can have an array of dchars" etc.). It should decide once 
and for all what its pointer aliasing and coercion rules are and 
not introduce a new function attribute every week on one hand and 
rely on hacks like "alias this" on the other. And then there is 
the tooling. D has dub but it's neither fully mature not 
universally used, which means that adding a 3rd party dependency 
to a project is much more of a chore than it needs to be (and 
should be).

>
> There are two effects I see where being opinionated is VERY 
> helpful - maybe essential - to a language.
> 1. Documentation and tutorials
> Tutorials need to be opinionated. People need to see ONE way to 
> do things when they learn. Once they understand, they can take 
> advantage of all the different ways, but they need to see a 
> path to success.
> 2. Whatever you expect people to do with the language, it needs 
> to be designed so there is at LEAST one way to do the above 
> things that is elegant. For example, web servers usually allow 
> some kind of annotation-based routing system. If you use Jetty 
> and you do your own routing, that is fairly confusing and 
> time-consuming. That is something where the annotation-based 
> method is a simple solution and allows you to not have to 
> discuss much about routing and that part of the framework to a 
> new user. It allows you to streamline. However, for Jetty (and 
> technically others), you don't HAVE to do it that way. It's 
> just the default way. Someone once said something like allow 
> endless configuration but provide sensible defaults. That's 
> what the D language is good at.
>
> I would like to read your response to this.

I've never personally used Jetty and admittedly web application 
development is not one of my areas of interest or expertise so I 
can't comment on that. On a more general level though, the notion 
of what is "elegant" is subjective. There should be at least one 
way that is idiomatic, well supported and proven to work for the 
proverbial 99% of the common cases. And if there is more than one 
way, then they should interoperate as easily as possible.