December 18, 2011
On 12/18/11 1:46 PM, jdrewsen wrote:
> On Sunday, 18 December 2011 at 17:19:33 UTC, Andrei Alexandrescu wrote:
>> On 12/18/11 6:19 AM, Alex Rønne Petersen wrote:
>>> On 18-12-2011 12:45, Somedude wrote:
>>>> Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
>>>>> I do not want to make a flame over D vs C++11.
>
> <snip>
>
>> Walter and I are both interested in making the GC precise.
>
> Wouldn't support for precise GC collection mean larger executable
> because type information is needed at runtime for precise collection?
>
> If so, could extra info be used to improve runtime reflection as well?

That is an interesting opportunity. At any rate, I am 100% convinced precise GC is the only way to go, and I think I've convinced Walter to a good extent as well.

Andrei


December 18, 2011
On 12/18/2011 11:51 AM, Ruslan Mullakhmetov wrote:
> On 2011-12-18 00:56:33 +0000, Timon Gehr said:
>
>> C++11 does not change the relation between D and C++ a lot. Why do you
>> think it does?
>
> Because it incorporates many features D declared to be unique to it

It does not, except for the most trivial stuff.

> over
> C++ like
> - thread local variables

D never declared that to be unique over C++. In D, thread local is the *default*. C++ does not have that, and it cannot have that.

> - explicit concurrency model

?

> - type deduction

C++11 cannot deduce function return value types. Except for lambdas. C++11 cannot pass template lambda functions as template parameters.

> - variadic templates

Yes, now you can pass a variable number of things to a C++ template. But what kind of things you can pass is still severely restricted.

> - generalized constant expressions

LOL! D has full CTFE. C++11's generalized constant expressions are a joke in comparison.

>
> Some comparison is made at http://d-programming-language.org/cpp0x.html
>
>> The language does not have to be changed to get that to work.
>
> The C language doesn't have to be changed to get OOP working. There are
> libraries written in plain C satisfying all requirements of OOP, e.g.
> libav. Nevertheless C++ was born.

This analogy is broken. D is expressive enough that there is no point in changing the language to support it. What part of MAS would require language support to be done nicely?

>
> So, what do i propose. To get it explicit in language and working out of
> the box, like in Erlang. the only benefit over Erlang i currently see
> that D is much more friendly for newcomers from C-like camp. The another
> is possibility for embedded programming. I was surprised that there are
> attempts to use MAS at embedded programming e.g. robotics where
> different controlers are autonomous and communicate with each others.
>
>>
>>> comparing to other modern languages
>>
>> IMO that is not a very important question. It is not a contest.
>
> I thin that this is exactly context. I try to explain. D has reputation
> of marginal language

D pushes the margin. :o)

> with no concrete niche.

It does not need a 'niche' and that is a good thing. D is general purpose. You can throw it at any task and expect good results. That is why MAS does not need explicit language support.





December 18, 2011
On 12/18/11 3:07 PM, Timon Gehr wrote:
> On 12/18/2011 11:51 AM, Ruslan Mullakhmetov wrote:
>> On 2011-12-18 00:56:33 +0000, Timon Gehr said:
>>
>>> C++11 does not change the relation between D and C++ a lot. Why do you
>>> think it does?
>>
>> Because it incorporates many features D declared to be unique to it
>
> It does not, except for the most trivial stuff.

I think it's best to not derail the argument into a D vs. C++ thing. Ruslan, what language and what library features do you envision should be added, and what would be their most likely applications?


Thanks,

Andrei

December 18, 2011
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
> That is an interesting opportunity. At any rate, I am 100% convinced precise GC is the only way to go, and I think I've convinced Walter to a good extent as well.

Sacrificing something (performance, executable size) for something else is not an unilateral improvement.
December 18, 2011
On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
>> That is an interesting opportunity. At any rate, I am 100% convinced
>> precise GC is the only way to go, and I think I've convinced Walter to
>> a good extent as well.
>
> Sacrificing something (performance, executable size) for something else
> is not an unilateral improvement.

It is an unilateral improvement if both options are kept open. I don't see a reason to cease support for the current GC model.

Furthermore, a generational GC performs much better than a simple mark-sweep GC.
December 18, 2011
Vladimir Panteleev:

> Sacrificing something (performance, executable size) for something else is not an unilateral improvement.

I presume they will add a very easy way (like a compilation switch? No need to modify druntime, or to recompile DMD, or to write your own GC) to switch back to less precise regime, or generally to avoid paying for things you don't want to pay. LDC compiler has pragmas to avoid specific typeinfos and moduleinfos, but it is a non portable thing and it's kind of low level.

Bye,
bearophile
December 18, 2011
On Sunday, 18 December 2011 at 23:02:17 UTC, Timon Gehr wrote:
> It is an unilateral improvement if both options are kept open. I don't see a reason to cease support for the current GC model.

I believe that currently the plan does not include providing this choice.

> Furthermore, a generational GC performs much better than a simple mark-sweep GC.

Unless you change the way references work, generational and "precise" aspects of a GC are orthogonal. Also, D can't have a completely precise GC as long as it has unions and can pass managed memory to C code.
December 18, 2011
On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
>> That is an interesting opportunity. At any rate, I am 100% convinced
>> precise GC is the only way to go, and I think I've convinced Walter to
>> a good extent as well.
>
> Sacrificing something (performance, executable size) for something else
> is not an unilateral improvement.

I think we can do a lot toward improving the footprint and performance of a precise GC while benefitting of its innate advantages.

Andrei
December 18, 2011
On 12/18/11 5:11 PM, Vladimir Panteleev wrote:
> Also, D can't have a completely precise
> GC as long as it has unions and can pass managed memory to C code.

Also casts pointer <-> integrals.

These arguments don't blunt the desirability of precise GC.


Andrei
December 18, 2011
On 12/19/2011 12:11 AM, Vladimir Panteleev wrote:
> On Sunday, 18 December 2011 at 23:02:17 UTC, Timon Gehr wrote:
>> It is an unilateral improvement if both options are kept open. I don't
>> see a reason to cease support for the current GC model.
>
> I believe that currently the plan does not include providing this choice.
>

That would strike me as odd. Andrei/Walter?

>> Furthermore, a generational GC performs much better than a simple
>> mark-sweep GC.
>
> Unless you change the way references work, generational and "precise"
> aspects of a GC are orthogonal.

You are right. I have had in mind a generational GC that uses a copying collector for the nursery as this is what most state-of-the-art VM GCs do.

> Also, D can't have a completely precise
> GC as long as it has unions and can pass managed memory to C code.

We can change the way unions are layed out. The compiler can mark GC memory passed to a C function as non-movable, or passing GC memory to a C function can be made illegal if the GC is enabled.