On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

My answere: Becaus it can't!

Some D greatest features are rejected by common developers (mainly for massive/productive profiles).

My favourite one is templates & mixins & compile time code:

People accepts to work with generics: a method signature is a contract and generic types can be part of the signature. It is easy to understand this:

 IIterable<R> map<T,R>(IIterable<T>, (T)=>R fmapper)

The languajge itself offers a native way to describe unambiguously what map accepts and returns... you can then read the comments to see what "map" means.

Even if the language offers optional typing, in the end you can deduce what each type is without actually compiling the code (the intellisence system itself can deduce it from the source code)

and D

You see the D map signature: It is Template syntax, not Type based signature syntax:

template map(fun...)

Then you enter in the code for details

auto map(Range)(Range r) if (isInputRange!(Unqual!Range))

What type auto refers? ... the "if" signature part tells us about verification methods, not Type dependent contracts. Ok, let's enter in the code more and more

return MapResult!(_fun, Range)(r);

Because Range is a "generic" type and previously you know it verifies isInputRange... then it refers to an InputRange. Good: auto is an input range :-)

But What exactly is an InputRange... is it an Interface? no: you must enter in the isInputRange implementation to see more details.

Good... but then... what is fun?
...

Of course, you have the documentation and the large descriptive comments that explains what signature can't and a complete chapter about ranges to understand how they work.

My point:

D introduces a different philosophy: you must accept conventions, don't expect to find Interfaces... That is not what a regular Scala/Typescript/Java/C#/... developer is used to seeing. It is a paradigm itself: your project will define more and more conventions (without the help of languaje native contracts) and compiler will check them.

Languages like Scala 3 or Typescript introduces new strong type flexibility with "union types" (i.e.: sayHello( who: "peter" | "andrew" ): string | string[] ) or exploid the pattern matching or .... but without losing the type based contracts

May be D is unpopular because it can't be popular.

On Wednesday, 3 November 2021 at 23:33:05 UTC, arco wrote:

How are you defining "day 1"? I stopped using Rust before version 1, and I can guarantee that there was nothing production quality about their compiler. Unless you mean by "day 1" the day version 1 was released - which was four years after the first release". When I checked Wikipedia to see these dates, I found this interesting quote

On Friday, 5 November 2021 at 15:54:53 UTC, Antonio wrote:

This kind of "convention-based" programming is actually very common in dynamic languages like Python and Ruby, where it goes by the name of "duck typing".

On Friday, 5 November 2021 at 16:02:45 UTC, bachmeier wrote:

Rust had a very erudite hardcore following from the start. Some people would argue about their proofs for various formulation of aspects of the type system in coq. Lots of showoff in the commentary… So they attracted people with compi.sci. background (and possibly students). In that sense they did not need to be productive from the start, they had fun with the type system etc.

I don't think this has been the case for D, but you could argue that those that created Tango also had fun with ideas (albeit in a less erudite manner).

I also don't think open source mattered much in the case of Go, like most Google products they are primarily developed by Google employees and these products tend to die/stagnate when Google stops development.

On Friday, 5 November 2021 at 13:42:44 UTC, Ola Fosheim Grøstad wrote:

What kind of application framework? something like .NET?

On Friday, 5 November 2021 at 15:30:51 UTC, Bruce Carneal wrote:

What's Mir and MLK?

On Saturday, 6 November 2021 at 03:20:30 UTC, Dr Machine Code wrote:

https://www.libmir.org/

https://en.m.wikipedia.org/wiki/Math_Kernel_Library

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

I used to use D a lot for hobby projects. But at some point, much of my code broke in ways that took me many hours to fix and still didn't get decent results. I forget the exact details, but I think one of the ones that caused me significant issues was something related to no longer being able to access private members in traits. And then eventually working around that, const just kept getting in the way for code that was previously okay. But during this, there were changes that sounded like improvements that weren't made in the spirit of not breaking code. All the while my code was breaking in very frustrating ways. There was also an aspect where the type of code I was writing (utilizes traits to generate runtime reflection recursively for types) would very frequently trigger new compiler/library bugs. I really enjoy the open source aspect of D and that I was able to make PRs to fix some of these bugs, but sometimes it was painful to figure out what was going on.

I'm going to be using D for one of the services in a project I'm working on soon as it's a good fit. I need a language that's easy to use, yet where I can have full memory control and native performance. Performance is the number one concern, and I won't need to use other cloud services or have many dependencies. D is a fantastic fit there, but I likely won't do it for too much more. In terms of language issues, personally the main thing that causes me frustration is issues with const and it just causing things to be... annoying when using templates (such as containers) or operators. Sometimes it feels like basics are missing from the standard library because they can be implemented using other constructs, but the way to do that isn't necessarily obvious.

The real problem though is not related to the language at all, it's just tooling and library support. I personally don't want to write a bunch of infrastructure around AWS to be able to deploy a Lambda that triggers from S3 events and reads/writes files while calling other AWS services. In addition, I've been very spoiled by the auto-complete present in languages like Go and C#, and it's really hard to go to a language that doesn't have virtually flawless completion (UFCS with templates and mixins inherently make these adding IDE features a nightmare I would think).

On Tuesday, 2 November 2021 at 17:27:25 UTC, Dr Machine Code wrote:

My point: it is because D is swimming against the current.

D tries to be a system language. And in this capacity few people need it.
Instead of moving against the flow, we could join the flow and overtake it.

What D is really good at?
D allows to do all the same things that can be done in application languages like Python, C# etc, only much better
D allows to write well-organized, well-readable code very quickly and this code executes very fast.

We need to stop fighting with C++ and attract those who write in languages like Python. We can give endless possibilities while preserving what such languages are loved for -- the speed of development.

On Saturday, 6 November 2021 at 07:29:25 UTC, valmat wrote:

In this case, Why do I use d? Don't other languages smell good?
Only dare to go against the current can we succeed.
D need to solve the unfriendly tool question.
I've heard many people say that they don't dare to use them , without good tools.