D1 to be discontinued on December 31, 2012

[Jakob Bornecrantz]

On Thursday, 15 December 2011 at 02:10:09 UTC, Walter Bright 
wrote:
> On 12/14/2011 4:32 PM, Jakob Bornecrantz wrote:
>> In short it can be answered with the questions "Can you
>> guarantee it work?"
>
> A guarantee would be something like you paid $x for it and I 
> would refund your $x if you weren't completely satisfied (which 
> I often do for Digital Mars C++ and other paid products). But I 
> don't see how I could offer a guarantee on a free product where 
> I have no control over your satisfaction.
>
>
>> and "Can I justify the amount of work I have
>> to put in for the gain?",
>
> That's something only you can answer.

Not the answer I was expecting for the first question, but it 
ultimately turned out to be the same, "you or anybody else can't, 
and neither can I." The point is I have something that works now 
moving to something new means risks and having to learn new 
things which ultimately ends up meaning time spent on other 
things then driving the project forward. I do realize there are 
some similarities with this argument and your argument for 
discontinuing D1 support, so I can't argue those reasons.

So the way I see it now, is there are some minor risks involved
and a upfront investment of time to convert the code, for no
real gain. Tho std.concurrency is looking pretty neat.

>> the thing is I have a had a lot of
>> problems with D1 toolchain, I have fixed or worked around these
>> issues and I'm wondering if I have to work around those or 
>> other
>> again. I am currently supporting 3 platforms (Mac, Linux &
>> Windows), so that factors in as well (me having fixed some
>> issues on Mac for D1).
>
> I can ask:
>
> 1. Are these issues all reported in Bugzilla?
> 2. Are your fixes also supplied to Bugzilla?
>
> With (1), I then will know about the issues, and myself or one 
> of the many contributors can supply a fix. With (2), I can 
> incorporate your fixes into the official toolchain so it will 
> never darken anyone else's doorstep again.

The issues I have ran into long ago, I'm pretty sure I haven't 
filed bugs about, sorry about that. The Mac platform issues I 
have: filed bugs for or reported me too's, generated pull 
requests, which have been pulled. So they are all resolved.

I think that my biggest fear is running into new bugs that I will 
have to waste a day or so of productivity on.

>> My current code base is 40Kloc's where about 8Kloc of those
>> are library bindings, on top of that it also includes a couple
>> of C projects sources (expat, lua and some other misc
>> libraries). So I would have to convert all that code to D2 and
>> also fix any issues that might arise from that conversion.
>> That said I think that it would mostly running the code
>> through dmd2 and just fix any cases where it complains. But it
>> probably wouldn't be a trivial amount of work.
>
> I don't know how much work that would be. I will say that 
> 40Kloc is not a huge base of code, as these things go. I don't 
> think you'll have to do anything with the C code or other non-D 
> sources.

My point was it would not be a non-trivial amount of work. You 
are of course correct that the non-D code would be left alone.

>> I don't use Phobos that much in my code so I wont have to
>> change much code with that regards, then again I don't see much
>> value of the new Phobos since there isn't much new there for 
>> me.
>> In fact I sort of have a philosophical disagreement with the
>> boost/templet-ification of it and the language in general.
>
> That's fair, but it's also something that could be a separate, 
> wide-ranging discussion.
>
>> Also in the beginning when I was using D1 and it moved much
>> more faster I would often find myself having to work around
>> or change various parts of the program due to new bugs or
>> features. I think D2 is much better in the bug department then
>> D1 was so that isn't much of a issue, but its still not really
>> stable and its more work for me.
>
> I understand the pain that breaking changes cause, and have 
> pushed hard to stop a few that I felt the minor gains on did 
> not justify the disruption.
>
>
>> That said there are a couple of features that if they where
>> implemented in D2 would encourage me to switch.
>>
>> One of the biggest problem right now is that I can't build
>> my project on Windows and is forced to cross compile it with 
>> GDC
>> from Linux. This stems from me having a mixed C & D project and
>> not getting the various compilers to get along (Both DMD & DMC
>> and GDC & GCC, would either not compile or produce broken
>> binaries). So making DMD work with the mingw toolchain on
>> Windows would be really appreciated (COFF support right?).
>
> I cannot help with this without knowing what the specific 
> problems are.

I can try and spend some time on this again. But the last time I 
tried I got random crashes inside the graphics driver with DMD & 
DMC while the same code cross compiled worked just fine. That was 
after a long day fighting various other versions of mingw-gdc 
trying to get it to work. I have to admit I at that point gave 
up. I know this is not ideal, sorry about that.

That said it might all work if I move to D2 and it might not, so 
there is that to factor into things as well.

>> Improvements to the GC, I'm currently having to thread lightly
>> around various issues with the GC, again its works currently so
>> I don't want to work around it again. Adopting a two step
>> approach employed by GObject would might help.
>> http://developer.gnome.org/gobject/stable/gobject-memory.html
>>
>>
>> All said and done, knowing what I know today I would probably
>> not do the project in D1, but I have thrown my dice and I'm
>> "stuck" (not used strongly here, I still like a lot of D), but
>> I'm not sure I would want to go through all that pain again
>> with D2. As Andrie have said D has a tendency to come unglued
>> when you start to do advanced thing, and the language dies a
>> death of a thousand paper-cuts (and some knife stabs).
>
> You don't have to write advanced code using D2. You can still 
> write "C style" code with it, and even "D1 style" code in it.

C style code is mostly what I have been doing anyways. I think 
the point I was trying to make is that D2 has the same unglued 
problem as D1. It might be different set of problems, but 
probably the same. That said C and C++ has its own set of 
problems and you just learn to work around those. If they differ 
from D1 to D2 I would have to relearn those.

That said I do have some advanced code in there, mostly relating 
to resource management, the code itself isn't, but writing it was 
a uphill battle against the GC. But I'm doing things not allowed, 
accessing objects from the dtor of a object. Those problems could 
be solved with the two step approach outlined by the link above.

>> I do appreciate the work you have put into D over the years,
>> I just don't want to have meaningless battles with language/-
>> compiler bugs. I hope this message is useful for you.
>
> It is, but I really do need more detail as outlined above.

I have tried to explain, I think my biggest concern is having to 
waste time for no gain.