This is why I don't use D.

[Patrick Schluter]

On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis 
wrote:
> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via 
> Digitalmars-d wrote:
>> On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via 
>> Digitalmars-d wrote: [...]
>>
>> > 3rd party libraries are usually the real problem if there is 
>> > one. They need to be maintained, and if something happens 
>> > that breaks them from one release to another, that can 
>> > prevent you from upgrading until it's fixed - which may or 
>> > may not be quick even if they're maintained. And if they're 
>> > not maintained, well, then that's a serious problem. Now, 
>> > that would be a big problem in pretty much any language, but 
>> > the greater rate of change in D does make it worse than it 
>> > would be in languages that change at a much more glacial 
>> > pace.
>>
>> [...]
>>
>> And that is why I think we should implement my idea of putting 
>> *all* dub packages on code.dlang.org into our CI 
>> infrastructure, and log all successes / failures to a database 
>> that can then be used to display the range of version(s) of 
>> compilers that successfully built each package on 
>> code.dlang.org. Then people can quickly see, at a glance, 
>> whether the package still works with the version of the 
>> compiler that they're using (usually the most recent release, 
>> but not always, so this information can be super useful in 
>> making decisions).
>
> Oh, I think that that's a good idea, and it should help with 
> folks picking libraries to use, but it doesn't fix the 
> fundamental problem that whoever wrote the library needs to 
> continue to maintain it or pass it on to someone else to 
> maintain it when they don't want to maintain it anymore, or 
> anyone using it is going to be screwed. So, while your 
> suggestion will definitely help with a piece of the problem, it 
> doesn't solve the part that I was talking about.
>

I have more radical proposition. Why not check regularly the 
maintainers of a library querying for feedback. If no response or 
negative response simply remove the package from the main list. 
Put it in a section for unmaintained projects.
It would not change fundamentaly the state of the packages, but 
would at least rein in on too high expectations.
OP would probably not reacted as badly as he did if he had known 
that the package he tried was unmaintained.
This might reduce the number of packages available, but it is 
often much better to have fewer choices than chosing the the 
wrong one (or two or three).