This is why I don't use D.

Everlast Everlast at For.Ever
Thu Sep 6 16:27:38 UTC 2018


On Thursday, 6 September 2018 at 13:08:00 UTC, Laurent Tréguier 
wrote:
> On Thursday, 6 September 2018 at 12:33:21 UTC, Everlast wrote:
>>
>> The problem is that all projects should be maintained. The 
>> issue, besides the tooling which can only reduce the problem 
>> to manageable levels, is that projects go stale over time.
>>
>> This is obvious! You say though "But we can't maintain every 
>> package, it is too much work"... and that is the problem, not 
>> that it is too much work but there are too many packages. This 
>> is the result of allowing everyone to build their own kitchen 
>> sink instead of having some type of common base types.
>
> I doubt having too many packages will be D's downfall. 
> Javascript is a thriving language even if tons of NPM packages 
> are unmaintained (and even if they still run, they potentially 
> have security vulnerabilities due to old dependencies).
>
>> It's sort of like most things now... say cell phone 
>> batteries... everyone makes a different one to their liking 
>> and so it is a big mess to find replacements after a few years.
>>
>>
>> See, suppose if there were only one package... and everyone 
>> maintained it. Then as people leave other people will come in 
>> in a continual basis and the package will always be maintained 
>> as long as people are using it.
>
> If we could have something as simple as "having the one and 
> only package that fits every use case", we wouldn't have 
> multiple OS's, multiple programming languages, etc.
> I do agree that having "the one" would make everything easier 
> in theory, but reality isn't theory.

You totally missed the point.

The point with 1 package only was to demonstrate how easy it is 
to maintain and that it theoretically would have the long 
longevity. When one has an infinite number of packages then every 
package(or almost everyone) would rot very quickly.

I didn't say there should actually only be one package, as that 
is absurd. What I said was that because D has no organizational 
structure to focus work on a fewer number of better maintained 
and designed packages there is a ton of shit out there for D that 
doesn't work but there is no way of knowing and not always an 
easy fix because it takes time to understand the code or it is 
simply defunct.

This is not rocket science...


More information about the Digitalmars-d mailing list