On 6/24/13 1:52 AM, OlliP wrote:
This is now a bit confusing to me. I just made up my mind to go
with D instead of Go, because Go is too simplistic in my opinion.
Furthermore, calling C from D is a lot easier than from Go. And
now this ... I have too little understanding of D to see what the
impact of this build time issue is. Does this mean build times
come close to what they are in C++ or is this issue only about
builds not being as fast as the D people are used to ..?
Thanks, Oliver
This forum is concerned with improving D and discussing its subtler
aspects. When a point is being argued, pedaling up or down certain
points is a common practice in attempting to make an argument stronger.
For example, "Currently, D suffers from a high degree of interdependency
between modules" could be more accurately (and boringly) be described as
"Currently, D's standard library is coarse-grained and favors internal
reuse over internal decomposition".
Such issues (and exaggerations thereof) are commonly found in this
newsgroup, for the simple reason this is the place to be for discussing
them.
This particular one is not stringent for our users, but it did come up
in internal testing (which instantiates all templates in large modules
such as std.algorithm). We have just implemented a proposal that allows
migrating from coarse-grained to fine-grained modularity in a library
(notably the standard library itself) without disrupting its clients.
Andrei
