On the panel discussion at Dconf day 3

[Adam Wilson]

On Saturday, 9 September 2023 at 19:06:24 UTC, ryuukk_ wrote:
> On Saturday, 9 September 2023 at 17:27:05 UTC, Paul Backus 
> wrote:
>> On Thursday, 7 September 2023 at 18:31:10 UTC, ryuukk_ wrote:
>>>> Ideas for new features for D have been deferred for the time 
>>>> being
>>>
>>> This is the saddest thing ever, i've been waiting for tagged 
>>> union / tuple since forever
>>>
>>> IVY = bureaucracy + religion, recipe for disaster, and we are 
>>> already seeing the effects: the language is now in a deep 
>>> freeze state
>>
>> On a project of D's size and scope, there is no such thing as 
>> "no bureaucracy." The only choice is between explicit, formal 
>> bureaucracy that's been designed intentionally; and implicit, 
>> informal bureaucracy that's been designed by accident.
>>
>> What we currently have is the implicit, informal kind of 
>> bureaucracy, which has all the disadvantages (hard to get 
>> things done) without any of the potential advantages (easy to 
>> keep track of what's being done and who's responsible). Moving 
>> away from this towards a more explicit system should be an 
>> easy win.
>
> I don't buy any of this, this is just a way to distance 
> yourself from the people who actually use the language and want 
> to solve problems, what tools are in there for those who don't 
> want to use EH/GC? nothing, does IVY has the answer? does IVY 
> people know how to program in C, do they know what competition 
> is doing?
>
> Tuple DIP predates this IVY thing, what are the excuses

For the moment EH is a problem, but it's known problem, and one 
that was discussed at length at DConf. From what I gathered 
Walter wants to move in the direction of a Herb Sutter style 
system where exceptions are returned up the stack silently via a 
shadow value in the return statement. It's actually a pretty 
elegant solution. It's not here now because of the pause, but 
it's coming because Walter wants it.

GC. Two points.

First there is @nogc and -vgc. Turn those on and the GC won't 
run. If your contention is that you want to use some parts of the 
language that use the GC, well, frankly, that's just too bad, 
your choices are either don't use those parts or submit a PR to 
rewrite those bits to not use the GC. Fortunately most of Phobos 
is available without the GC so I don't really see what the 
problem is.

Second, if your contention is that the GC *exists at all* and 
that's bad and it should be removed... I have bad news. I asked 
Walter whether or not he would ever sanction removing the GC and 
his answer was "Never. GC code is inherently memory safe code." 
which means that as memory safety is one of D's key selling 
points, the GC is here to stay. In fact there are efforts 
underway to improve the performance of the GC considerably.

Tools exist to disable the GC at runtime, if you don't want the 
GC, use them. The rest of us will happily go on using the GC and 
this is a non-issue.