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.
