| |
![Adam Wilson's Gravatar profile Gravatar of Adam Wilson](//www.gravatar.com/avatar/5bd81b717e26c40ebcf08682bd4d35f5?d=identicon&s=32) | Posted by Adam Wilson in reply to ryuukk_ | Permalink Reply |
|
Adam Wilson ![Adam Wilson's Gravatar profile Gravatar of Adam Wilson](//www.gravatar.com/avatar/5bd81b717e26c40ebcf08682bd4d35f5?d=identicon&s=80)
Posted in reply to ryuukk_
| 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.
|