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.

Reply via email to