https://forum.dlang.org/post/vnkgayrbnokeufduuuba@forum.dlang.org

On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
> First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion.
>
> [...]

General question: how much of this is still true?

On Friday, 8 October 2021 at 15:45:10 UTC, Imperatorn wrote:
> https://forum.dlang.org/post/vnkgayrbnokeufduuuba@forum.dlang.org
>
> On Friday, 2 February 2018 at 15:06:35 UTC, Benny wrote:
>> First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion.
>>
>> [...]
>
> General question: how much of this is still true?

All of it's still true.

On Friday, 8 October 2021 at 15:45:10 UTC, Imperatorn wrote:
> General question: how much of this is still true?

I'd say a lot of it is still true. Especially in terms of packages.

In languages like Go and C# you get standard interfaces for a lot of things (logging, HTTP, etc.). This means libraries all share a common ground to work together with, even when you use third party frameworks (Gin builds off of Go's standard HTTP stuff, Giraffe sits on top of ASP Core, C# graphql libraries integrate with the standard dependency injection stuff, etc.)

In D you have experimental packages at best, and dead dub packages at (common) worst. And libraries have no real integration with one another.

Everyone seems to prefer writing their own code, because for one reason or another, existing code just doesn't work/suit their use case/whatever, thus leading to most packages simply dying due to lack of interest, lack of maintainers, and so on.

D supports too many paradigms and wildly different usages (gc, nogc, betterc) that unless a package is completely "perfect", it seems to just be dropped off peoples' radars.

Is this even as big an issue as I feel it is? No clue.

Is there something we can even do about it? No clue.

And I've gone on about this a bit before, but in terms of a "get shit done" language, D isn't much of a competitor. If I want to get something tapped out quick and easy, I'd rather use C# or Go where everything is well tested, mostly well documented, and I don't have to deal with C libraries just to bridge the gaps in missing functionality (especially making sure the code builds cross-platform).

Bonus points is that I get to use a VSCode plugin that works more than 50% of the time, and is able to cover most of the language features. That's not a dig at code-d btw since I'm sure it does the best it can manage with D's flexible syntax.

In other words, there's just a lot of friction getting things done with this language, even though the benefits of the language itself are mostly worth the effort, sometimes it's just easier to drop to a more straightforward language + libraries.

With other languages I get the feeling of people rallying around specific things and the language itself, while with D I get the feeling of everyone being spread out, and only occasionally gathering together once in a while.

On Friday, 8 October 2021 at 18:05:47 UTC, SealabJaster wrote:
> And I've gone on about this a bit before, but in terms of a "get shit done" language, D isn't much of a competitor. If I want to get something tapped out quick and easy, I'd rather use C# or Go where everything is well tested, mostly well documented, and I don't have to deal with C libraries just to bridge the gaps in missing functionality (especially making sure the code builds cross-platform).

Are you talking about C# and Go with only their standard libraries or with additional libraries. In the latter case it would be difficult for any small language to compete, but if we make the assumption that projects only use the standard library then there is an argument to be made for creating a streamlined programming experience with a sensible default setup.

But one still needs to define the typical use scenario in order to determine what the best choice is… It is basically impossible to design in a vacuum, then one ends up with a mishmash of opinions.