Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
>> characteristics for basic infrastructure. People shouldn't 
>> have to rewrite their entire stack every 6 months just because 
>> someone thought of a better API for some low-level component.
>
> Then don't use libraries from unreliable teams.

Just using the standard library whenever possible is a simple and 
efficient way of accomplishing this - if the standard library 
actually has anything in it...

>> Making it through D's formal review process typically raises 
>> code quality quite a lot, and the knowledge that backwards 
>> compatibility is a high priority makes outsiders much more 
>> likely to invest in actually using a library module.
>
> Code quality is one thing, but if it has not been used in many 
> applications, how can you then know if the abstraction is 
> particularly useful?

This is why requiring modules to spend some time on DUB and/or in 
`std.experimental` before freezing the API is important.

> In general the standard library should just be the most basic 
> things, even file system support is tricky for a system level 
> programming language. For instance, on some cloud platforms you 
> don't get to read/write parts of a file. You do it as one big 
> atomic write/read.

Targeting 100% generality with APIs is pretty much always a bad 
idea.

Standard libary modules should endeavor to meet the needs of at 
least, say, 80% of potential users; they're not supposed to 
completely eliminate the need for specialized third-party 
libraries entirely. This is OK, because if you don't use a 
module, the compiler won't include it in the final executable.