Back in D after some absence, some perspective

[Dukc]

On Tuesday, 2 March 2021 at 21:05:14 UTC, deadalnix wrote:
>
> In any case, a common pattern across several of these bugs was 
> a poor handling of the "empty" case. For instance 
> https://github.com/dlang/phobos/pull/7788 was due to a problem 
> where std.csv did not handle empty csv files and would report 
> at least one row.

Easy to see. Just yesterday a range I had just done (for my own 
project) malfunctioned exactly because it's so easy to screw the 
empty range thing up.

> Another major pain point was dub. It is wonderful to get 
> something up and running quickly, but then turn into a 
> nightmare when it come to packaging and distribution. The root 
> cause seems to be that dub tries to be too many things at once, 
> such as a dependency manager and a build system.

How so? When making a distribution package, just bundle the DUB 
packages, or distribute `dub.selections.json` with the source 
code and have your package to checksum the final binary.

>
> The awesome:
> The support I got through all of this was first class. I don't 
> know if this is because it's me and people know me or if this 
> is general, but it is way better than a couple of years ago and 
> bugs gets fixed way faster.

Probably in no small part due to D language foundation and the 
people they have hired to make sure contributions keep moving. 
Take DIPs for instance, a few years ago the process worked only 
randomly, now we have DIP after DIP, with like three or so 
accepted per year. The process works slowly and the quality of 
the decisions is sometimes debatable, but no DIP will stall 
forever anymore because of the DIP management/maintainers.

>
> If that pace can be sustained without introducing too many 
> regressions, then I doubt I'll be running into bugs on a 
> regular basis.

Both the compiler and the library have even heavier test suite 
than a few years ago, it easily catches the vast majority of 
regressions we'd have otherwise. Unfortunately it is so heavy it 
also slows down development considerably. And there are many 
cases where it's difficult to be sure what's the correct 
behaviour. Many instabilities result just because the user code 
accidently relies on such loosely defined behaviour.

>
> One word of advice:
> I see that new features are being added still, such as the 
> recent addition of noreturn. While this is a good addition, 
> such a case can be made for a bazillion other features too. I 
> think it is hard too argue that D doesn't have enough feature 
> at this time. In my experience, running into bugs and 
> difficulty to integrate into existing systems, workflows, 
> dependency management, and so on is whee it's at.
>
> D has reached a point where it needs to heavily focus on its 
> toolchain, as well as ensuring the soundness of what's there, 
> nailing small inconsistencies, etc...

Those are real issues, but I don't think stagnating the 
development just to let the language to stabilize is any better 
overall.

Instead we need ways for the new code to work with old code. 
Perhaps something like declaring the language version and 
compiler preview switches in module headers.