What changes to D would you like to pay for?

[Adam D. Ruppe]

On Friday, 7 September 2018 at 11:48:47 UTC, RhyS wrote:
> ... Sorry Adam but if you consider a collection of lose code 
> production ready for D, then we have different ideas. ;)

All libraries are collections of loose code, except the bad ones, 
which are tightly coupled collections of code that break with 
random dependency updates.

My code hasn't had serious breakage for years. Every so often, a 
new dmd release will through up a deprecation warning, but I fix 
those and keep it working on both old and new. I actively test 
compiling cgi.d, for example, on D 2.069, which is from 2015! It 
works there as well as the newest release this week.

That's the power of loosely coupled, conservatively-coded 
modules: they are hard to break. You pick and choose the parts 
you need, without pulling in a huge, fragile dependency tree.

I (and others) have also used it on real-world applications 
continuously since 2011.

> * Not included into D / External maintained by one dev.

You don't need a huge dev team when you have a stable, 
encapsulated codebase - maintenance is easy since things don't 
randomly break!

> * Not "user friendly" / Documentation is ... be honest Adam ;)

http://arsd-official.dpldocs.info/arsd.cgi.html

I rank it as... OK. But it is also generally simple so there's 
not that much to look at.

> Its the most neutral and realistic benchmark for Web related 
> content. When PHP with its bootstrapping fire and forget 
> approach beats D by 50%, you know D has a issue.

well, plain php is actually hard to beat for simple things. But 
yeah, vibe's performance there is poor. I wonder if I'd beat it, 
despite my policy being compatibility, stability and simplicity 
over performance.