This is why I don't use D.

[JN]

On Wednesday, 5 September 2018 at 06:16:57 UTC, Neia Neutuladh 
wrote:
> On Wednesday, 5 September 2018 at 05:44:38 UTC, H. S. Teoh 
> wrote:
>> To me, this strongly suggests the following idea:
>> - add *all* dlang.org packages to our current autotester / CI
>>   infrastructure.
>> - if a particular (version of a) package builds successfully, 
>> log the
>>   compiler version / git hash / package version to a database 
>> and add
>>   a note to dlang.org that this package built successfully 
>> with this
>>   compiler version.

Might be hard to definen what does it mean to "build 
successfully". Many D packages love their metaprogramming, so 
just building the package might be enough. Unit tests might even 
pass, but when trying to use it in an application it might fail 
in compilation.

I agree however that dub needs some mechanism of marking outdated 
packages. I think it'd be healthy for D ecosystem in the long run 
in general. There were a few times when I wanted to implement 
some functionality, I was like "oh, there's obviously a dub 
package for that". And there were, seven of them. Turns out two 
were just an experiment, four didn't compile anymore (not 
maintained since 2016), the last one worked, but I had to use a 
git dev branch, because the one in the repository wasn't working 
properly.

I commonly see an argument for putting things like logging, 
serialization, archive support out of standard library and into 
dub packages. I think it has some merit, but one of the main 
advantages of having stuff in the standard library is that it's 
commonly used and tested. I can expect std.experimental.logging, 
std.zip to always work, because they are properly tested as part 
of D release process.