December 11, 2011
so Wrote:

> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org> wrote:
> 
> > Really?
> >
> > Tell that to all game studios developing games in Java/C#/Flash.
> >
> > Do you know that many games in iPhone are done in Unity, which makes use of C#/Boo/Javascript compiled to native code?
> 
> I don't understand sorry, are you arguing against the argument i made on GCs failure on some specific areas?

Come on kidz, GC does good on some tasks that are not performance critical, it fails on other tasks that are. That is why D has assembler option - for parts you need to be done ultra fast. Same should apply for optional  GC. And everyone gets candy :)
December 11, 2011
Paulo Pinto Wrote:

> Am 11.12.2011 17:12, schrieb Bane:
> > Paulo Pinto Wrote:
> > But in systems world there will always be significant number of people with doubt in any GC implementation, or just with a desire to do their own memory management. I think that group of people is important and we should do what we can to attract them to D.
> >
> 
> Those people will eventually become irrelevant.
> 
> As I mentioned in a previous email, if I want to use a language without GC for systems programming I already have C, C++, Delphi, you name it. Why pick D then?
> 

Because people are lazy and hate to learn new language, they will try to do that in one they already know or already like. If D offers them tools to do MMM then they have no need to resort  to C,C++ for anything anymore thus it really replaces them....

December 11, 2011
"Dejan Lekic" <dejan.lekic@gmail.com> wrote in message news:vuwuhxcsxbdpdjxpwhvj@dfeed.kimsufi.thecybershadow.net...
>
> Problem with D and Phobos is that there is no clear roadmap (or at least I am not aware of its existence). So please tell me how you guys know if dmd+phobos is ready to be released or not when there was no plan on what this release is all about (apart from the list of issues on bugzilla)???
>

When there's enough worthwhile improvements, and the DMD beta mailing list determines it doesn't have any big problems, like regressions, etc.  Good enough for me. I see no benefit in adding red tape for the sake of having more red tape.


December 11, 2011
Am 11.12.2011 17:40, schrieb so:
> On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto <pjmlp@progtools.org>
> wrote:
>
>> Really?
>>
>> Tell that to all game studios developing games in Java/C#/Flash.
>>
>> Do you know that many games in iPhone are done in Unity, which
>> makes use of C#/Boo/Javascript compiled to native code?
>
> I don't understand sorry, are you arguing against the argument i made on
> GCs failure on some specific areas?

Yes I am, since I know many areas where GC enabled languages have been replacing non-GC languages for better or worse.

But then again, I am only a lurker here, so take my arguments with a grain of salt.

As a non user of D, I cannot really say much.
December 11, 2011
On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:
> On 12/11/11 9:14 AM, Chad J wrote:
>>
>> I think one thing that could would be (optional) reference counting for transitively atomic types.  Of course, this is just another kind of garbage collection, but it is /deterministic/ and parallelizes well, and I bet this would open up a large amount of Phobos while the stop-the-world collector is offline, and with little or no code change.
> 
> I think the language has enough (in theory) and nearly enough (in
> practice) expressiveness to implement reference counted classes in a
> library, virtually transparently. I mean one could define a template
> RefCounted (an extended version of what's now in std) such that this
> pattern is possible:
> 
> // client code
> class WidgetImpl {
>   ...
> }
> 
> alias RefCounted!WidgetImpl Widget;
> 
> Aside from using WidgetImpl in type relationships, using Widget would transparently insert the appropriate reference counting without otherwise interfering with normal WidgetImpl semantics.
> 
> 
> Andrei

This is good.  So stick it in the runtime and make the compiler emit RefCounted!___ templates whenever it finds a transitively atomic type.

This can be done alongside the existing garbage collector.

Then we can benchmark different combinations of memory management strategies.

Two compiler flags can work in tandem:
-nogc
-norefcount

(Turn them both off if you really want to break Phobos.)

December 11, 2011
On 11 December 2011 15:15, maarten van damme <maartenvd1994@gmail.com>wrote:

>
> 2011/12/11 Paulo Pinto <pjmlp@progtools.org>
>
>> Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:
>>
>>> On 12/10/11 2:22 PM, maarten van damme wrote:
>>>
>>>> Just for fun I
>>>> wanted to create a program as little as possible, compiled without
>>>> garbage collector/phobos/... and it turned out that compiling without
>>>> garbage collector is pretty much impossible (memory leaks all around the
>>>> place in druntime). dynamic linking for the d standard library would be
>>>> a great new option for a dmd release in the future :).
>>>>
>>>
>>> Using D without GC is an interesting direction, and dynamic linking should be available relatively soon.
>>>
>>>
>>> Andrei
>>>
>>
>> As a long time beliver in systems programming languages with GC support (Modula-3, Oberon, Sing#, ...), I think allowing this in D is the wrong direction.
>>
>> Sure provinding APIs to control GC behavior makes sense, but not turn it off, we already have enough languages to do systems programming without GC.
>>
>
> I was only trying it "for the fun of it", not to be used seriously. D should always have it's GC support built-in and have some functions to control it's behaviour (core.memory). But I think that D, beeing a systems programming language, should also be able to be used without GC. I don't mean phobos to be writtin without a GC in mind but druntime should be compilable with something like a -nogc flag that make it usable without GC.
>
> There are a lot of users out there who think that a GC produces terribly
> slow programs, big hangs while collecting,... (thank java for that. Right
> now the java GC has been improved and it's extremely good but the memory
> stays :p)
> Letting them know that D can be run without GC can be a good point. If
> they don't like it, they can turn it off.
>

That's got nothing to do with it. People who seriously NEED to be able to
use the language without the GC enabled are probably working on small
embedded systems with extremely limited resources. It's also possible that
various different resource types need to be allocated/located in different
places.
Also, In many cases, you need to able to have confidence in strict
deterministic allocation patterns. You can't do that with a GC enabled.
I'm all about having a GC in D, obviously, but I certainly couldn't
consider the language for universal adoption in many of my projects without
the option to control/disable it at times.
If I can't write some small programs with the GC completely disabled, then
I basically can't work on microprocessors. It's fair to give up the
standard library when working in this environment, but druntine, the
fundamental library, probably still needs to work. Infact, I'd personally
like it if it was designed in such a way that it never used the GC under
any circumstances. No library FORCED on me should restrict my usage of the
language in such a way.


December 11, 2011
Am 11.12.2011 19:18, schrieb Manu:
> On 11 December 2011 15:15, maarten van damme <maartenvd1994@gmail.com
> <mailto:maartenvd1994@gmail.com>> wrote:
>
>
>     2011/12/11 Paulo Pinto <pjmlp@progtools.org
>     <mailto:pjmlp@progtools.org>>
>
>         Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:
>
>             On 12/10/11 2:22 PM, maarten van damme wrote:
>
>                 Just for fun I
>                 wanted to create a program as little as possible,
>                 compiled without
>                 garbage collector/phobos/... and it turned out that
>                 compiling without
>                 garbage collector is pretty much impossible (memory
>                 leaks all around the
>                 place in druntime). dynamic linking for the d standard
>                 library would be
>                 a great new option for a dmd release in the future :).
>
>
>             Using D without GC is an interesting direction, and dynamic
>             linking
>             should be available relatively soon.
>
>
>             Andrei
>
>
>         As a long time beliver in systems programming languages with GC
>         support
>         (Modula-3, Oberon, Sing#, ...), I think allowing this in D is
>         the wrong direction.
>
>         Sure provinding APIs to control GC behavior makes sense, but not
>         turn it
>         off, we already have enough languages to do systems programming
>         without GC.
>
>
>     I was only trying it "for the fun of it", not to be used seriously.
>     D should always have it's GC support built-in and have some
>     functions to control it's behaviour (core.memory). But I think that
>     D, beeing a systems programming language, should also be able to be
>     used without GC. I don't mean phobos to be writtin without a GC in
>     mind but druntime should be compilable with something like a -nogc
>     flag that make it usable without GC.
>
>     There are a lot of users out there who think that a GC produces
>     terribly slow programs, big hangs while collecting,... (thank java
>     for that. Right now the java GC has been improved and it's extremely
>     good but the memory stays :p)
>     Letting them know that D can be run without GC can be a good point.
>     If they don't like it, they can turn it off.
>
>
> That's got nothing to do with it. People who seriously NEED to be able
> to use the language without the GC enabled are probably working on small
> embedded systems with extremely limited resources. It's also possible
> that various different resource types need to be allocated/located in
> different places.
> Also, In many cases, you need to able to have confidence in strict
> deterministic allocation patterns. You can't do that with a GC enabled.
> I'm all about having a GC in D, obviously, but I certainly couldn't
> consider the language for universal adoption in many of my projects
> without the option to control/disable it at times.
> If I can't write some small programs with the GC completely disabled,
> then I basically can't work on microprocessors. It's fair to give up the
> standard library when working in this environment, but druntine, the
> fundamental library, probably still needs to work. Infact, I'd
> personally like it if it was designed in such a way that it never used
> the GC under any circumstances. No library FORCED on me should restrict
> my usage of the language in such a way.

In my experience programming embedded systems in highly constrained environments usually means assembly or at most a C compiler using lots
of compiler specific extensions for the target environment.

I fail to see how D without GC could be a better tool in such enviroments.


December 11, 2011
El 11/12/2011 16:14, Chad J escribió:
> On 12/11/2011 08:15 AM, maarten van damme wrote:
>> ...
> I think one thing that could would be (optional) reference counting for
> transitively atomic types.  Of course, this is just another kind of
> garbage collection, but it is /deterministic/ and parallelizes well, and
> I bet this would open up a large amount of Phobos while the
> stop-the-world collector is offline, and with little or no code change.
>
> The big example in my mind is strings.  Strings are straight-up atomic.
>   They can't have the reference cycles that would confuse a reference
> counter.  And if we allowed them to be reference-counted, then all of
> the string functions using copy-on-write would now work with the
> stop-the-world collector disabled.
>

Yes, an alternative to GC is reference counting with immediate destruction. It is used for instance in Vala (a language on top of the GObject system, a bit reminiscent of D):

http://live.gnome.org/Vala/ReferenceHandling

But I think it would be too complicated to turn all D's arrays, objects, etc. into a system like this.
December 11, 2011
I wish to add a little of why Mehrdad's complaints are very important. I think the delay is a good, over releasing 2.058 two days later.

Most in the community have chosen what they will use of D, they know of some issues (no multiple alias this), or don't know how best to use something (concurrency).

In our marketing for the language we express how great such-and-such is, but know that problems will be found by those that use it. We could not mention concurrency and how immutable/const plays its rule, but we need to answer what is different from D1 and how the future of computing will be easier in D.

Interestingly Mehrdad has chosen something which does basically nothing, the const system. Const isn't important at _all_, except that it is a pillar for our functional concurrent purity. We claim a language that makes an immutable and mutable world coexist. Yet the implementation doesn't back that up.

So why should we probably finish fixing up const, over say the multiple alias this, @safe, or no GC use? Because it is what will be touched by new users the most. You tell people how great mixing immutable and mutable is, they're going to give it a try. You pull users over from C++ or other languages with non-transitive const, they are going to use const as they do in that language without reading about how D does it. These people aren't going to be using const correctly in D, they couldn't possibly know how to. When they complain, we explain what is wrong and how they should be using it, but when they do start using it correctly (because they won't listen to our "don't use const yet" message) they will still fail to get it right because implementation doesn't support it.

We need to be able to prove transitive const is easy to work with and worth it. Transitive const is hard to see how it works, but no GC and explaining multiple alias this is simple to understand. And @safe D is not what brings people to D.

There was a concentration on TDPL bugs before the book came out, lets bring that back and get them done for 2.058: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&short_desc=tdpl&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&short_desc_type=allwordssubstr

What do you say team?
December 11, 2011
On 12/11/11 12:17 PM, Chad J wrote:
> On 12/11/2011 11:21 AM, Andrei Alexandrescu wrote:
>> On 12/11/11 9:14 AM, Chad J wrote:
>>>
>>> I think one thing that could would be (optional) reference counting for
>>> transitively atomic types.  Of course, this is just another kind of
>>> garbage collection, but it is /deterministic/ and parallelizes well, and
>>> I bet this would open up a large amount of Phobos while the
>>> stop-the-world collector is offline, and with little or no code change.
>>
>> I think the language has enough (in theory) and nearly enough (in
>> practice) expressiveness to implement reference counted classes in a
>> library, virtually transparently. I mean one could define a template
>> RefCounted (an extended version of what's now in std) such that this
>> pattern is possible:
>>
>> // client code
>> class WidgetImpl {
>>    ...
>> }
>>
>> alias RefCounted!WidgetImpl Widget;
>>
>> Aside from using WidgetImpl in type relationships, using Widget would
>> transparently insert the appropriate reference counting without
>> otherwise interfering with normal WidgetImpl semantics.
>>
>>
>> Andrei
>
> This is good.  So stick it in the runtime and make the compiler emit
> RefCounted!___ templates whenever it finds a transitively atomic type.
>
> This can be done alongside the existing garbage collector.
>
> Then we can benchmark different combinations of memory management
> strategies.
>
> Two compiler flags can work in tandem:
> -nogc
> -norefcount
>
> (Turn them both off if you really want to break Phobos.)

We considered that route, and concluded it's marred by too many issues.

Andrei