On Mon, Jun 24, 2013 at 1:52 AM, OlliP <jeti789@web.de> 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
>
>
>
> On Saturday, 22 June 2013 at 04:45:31 UTC, Timothee Cour wrote:
>
>> A)
>> Currently, D suffers from a high degree of interdependency between
>> modules;
>> when one wants to use a single symbol (say std.traits.isInputRange), we
>> pull out all of std.traits, which in turn pulls out all of
>> std.array,std.string, etc. This results in slow compile times (relatively
>> to the case where we didn't have to pull all this), and fat binaries: see
>> example in point "D)" below.
>>
>> This has been discussed many times before, and some people have suggested
>> breaking modules into submodules such as: std.range.traits, etc to
>> mitigate
>> this a little, however this requires people to change 'import std.range'
>> to 'import std.range.traits' to benefit from it, and also in many cases
>> this will be ineffective.
>>
>> B)
>> I'd like to propose something different that can potentially dramatically
>> reduce compile time/binary size, while not requiring users to scar their
>> source code as above.
>> ....
>>
>

see timings in my original post above or try for yourself, it is already much faster than C++ (and even go as reported by some). But I'm talking here about a proposal to enable interactive time for compiling projects (ie even faster and using less memory).

On Monday, 24 June 2013 at 00:23:53 UTC, Martin Nowak wrote:
> On 06/22/2013 11:20 AM, Dicebot wrote:
>> D has "export" keyword that I always expected to do exactly this until
>> have found out it is actually platform-dependent and useless.
> It's buggy and useful.
> http://d.puremagic.com/issues/show_bug.cgi?id=9816
> We should try to strive for -fvisibility=hidden on UNIX because it allows to optimize non-exported symbols and because we need explicit exports for anyhow.

I think it will be useful only when usage of "-fvisibility=hidden" will be mandatory by spec. It is one of tools that need to provide strict guarantees to be successfully abused.

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

On 2013-06-24 09:35, JS wrote:

> It should be possible to "export"(or rather "share") types,
> mixins, templates, generic unit tests, etc. (shared compile time
> constructs would just be "copied" to a shared library as they
> can't be compiled)

These are compile time entities. I don't see why they need to be in a library at all. Just having them in the source/interface files is enough.

-- 
/Jacob Carlborg

On Monday, 24 June 2013 at 20:48:49 UTC, Jacob Carlborg wrote:
> On 2013-06-24 09:35, JS wrote:
>
>> It should be possible to "export"(or rather "share") types,
>> mixins, templates, generic unit tests, etc. (shared compile time
>> constructs would just be "copied" to a shared library as they
>> can't be compiled)
>
> These are compile time entities. I don't see why they need to be in a library at all. Just having them in the source/interface files is enough.


Having one file to share is better than many. It makes it easier to version, easier to maintain, and easier to distribute.

It is better than just zipping the collection of files, e.g. jar's, because it allows for better structural encoding but is effectively the same. Utilities can be used to extract/view specific information if needed.

The main benefit is versioning. One never has to worry about different parts of the library being out of sync because *everything* is compiled to one file. There is nothing to maintain except the source code.

On Monday, 24 June 2013 at 08:52:47 UTC, 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
>

D build times are quite fast. An ongoing compiler port from Java to D I have been doing does a full build in less than 2s.

Go build times are nothing to be amazed, for the developers that grown up with Basic, Modula-2 and Pascal dialect compilers back in the 80's in the hardware constraints of those days.

C and C++ success in the mainstream created a misconception of what compile times of native languages mean.

--
Paulo

On 2013-06-24 23:33, JS wrote:

> Having one file to share is better than many. It makes it easier to
> version, easier to maintain, and easier to distribute.
>
> It is better than just zipping the collection of files, e.g. jar's,
> because it allows for better structural encoding but is effectively the
> same. Utilities can be used to extract/view specific information if needed.
>
> The main benefit is versioning. One never has to worry about different
> parts of the library being out of sync because *everything* is compiled
> to one file. There is nothing to maintain except the source code.

Are you meaning we should put all the source code/.di files into the libraries? The library will then both provide the API and the implementation.

-- 
/Jacob Carlborg

On Tuesday, 25 June 2013 at 09:35:52 UTC, Jacob Carlborg wrote:
> On 2013-06-24 23:33, JS wrote:
>
>> Having one file to share is better than many. It makes it easier to
>> version, easier to maintain, and easier to distribute.
>>
>> It is better than just zipping the collection of files, e.g. jar's,
>> because it allows for better structural encoding but is effectively the
>> same. Utilities can be used to extract/view specific information if needed.
>>
>> The main benefit is versioning. One never has to worry about different
>> parts of the library being out of sync because *everything* is compiled
>> to one file. There is nothing to maintain except the source code.
>
> Are you meaning we should put all the source code/.di files into the libraries? The library will then both provide the API and the implementation.

While one could do that it generally isn't necessary or even desirable.

The compile time constructs I mentioned are required to use the library(e.g., interfaces) or useful for debugging/testing(generic unit tests and contracts).

One could add the ability to include the source code for debugging purpose if desired.

The idea is rather simple. Suppose you are writing a library. You design some code, some unit tests and contracts. Suppose you have to pass around delegates/functions between your library and user code.

Do you require the user to implement the unit tests and contracts? Does he have to copy and paste? Why not just have some type of generic unit test and contract that the user can call on his functions to make sure they pass *your* tests? If you can include them in your library then they can act like normal meta functions that can be used without requiring the user to see the guts.