Hi all,

As you might know, I was very active a couple of years ago and then got driven away, mostly by work, family and so on. But I've been back for a couple of month now and I thought I'd write a little about what changed on larger time scale. It is not always easy to see this when being in D on a day to day basis, so I thought this would be valuable feedback for everybody.

The bad:
I ran into many bugs still, mostly in phobos. This might indicate that code was merged in before it was really ready and that we are paying back that debt, or that the language has accumulated too much complexity and that it is hard target these things right.

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.

That should probably be added to the checklist of test case to have for something to be considered mergeable. Not sure it is automatable, but human can use their judgement to get it sorted out.

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.

The good:
No more ICE! At least I haven't run into any so far.

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.

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

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...

On Tue, Mar 02, 2021 at 09:05:14PM +0000, deadalnix via Digitalmars-d wrote: [...]
> As you might know, I was very active a couple of years ago and then got driven away, mostly by work, family and so on. But I've been back for a couple of month now and I thought I'd write a little about what changed on larger time scale. It is not always easy to see this when being in D on a day to day basis, so I thought this would be valuable feedback for everybody.

Very valuable indeed!


> The bad:
> I ran into many bugs still, mostly in phobos.
[...]
> In any case, a common pattern across several of these bugs was a poor handling of the "empty" case.
[...]
> That should probably be added to the checklist of test case to have for something to be considered mergeable. Not sure it is automatable, but human can use their judgement to get it sorted out.

I think there should be an official checklist of test cases that need to be covered before a PR is merged.  Of course it can't be a precise checklist because every PR is different, but without an official, written guideline, it's too easy to just forget about this or that corner case and unknowingly introduce bugs.


> 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.

I've been staying away from dub precisely because of the above architectural issues, but telling people to stay away is not a viable solution.  I don't know how to solve this problem without completely redesigning dub, though.  It's too entrenched to change now, and we don't want to lose the ecosystem that has been painstakingly built up around it.


> The good:
> No more ICE! At least I haven't run into any so far.

Yay!


> 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.

I think now that the foundation has hired a couple of people to handle the mundane, day-to-day chores, there's been more grease in the gears and things are running a little more smoothly now. Hopefully this will continue into the future.


[...]
> 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...

Yeah, the small inconsistencies really need to be fixed. They may be small, minor details from a language perspective, but these minor details cause a domino effect of weird corner cases that cause pain down the road, esp. to newcomers unfamiliar with the gotchas involved. These corner cases really need to be smoothed out.

Also, to mention another (relatively) recent awesome development: LDC has been supporting almost out-of-the-box cross-compilation from Linux to Windows, and I've been really enjoying that. All it takes now is just to download and unpack LDC for Linux and LDC for Windows, then add a block to the config file, and it's all set for heavy-duty cross-compilation.

Also, if you ever need to interface with Java, check out Adam's jni.d. Metaprogramming awesomeness that makes it so easy to interface D with Java, I'm actually starting to lose some of my dislike for Java. :-D


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes

On Tuesday, 2 March 2021 at 21:05:14 UTC, deadalnix wrote:

> 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 don't see this as a new feature - it's more like a fix for a glaring hole in the type system, that now removes a few corner cases that prevented generic coding in some places. But it was of course a big enough change to require a DIP.

I think this is the kind of "features" that really should go into the language: things that _remove_ corner cases. The same is true for the @safe/@system variables and for type functions.

In contrast to new "syntactic sugar" like named parameters or interpolated strings, which I also like but which are more debatable.

It's great to have you back!

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.

On Tuesday, 2 March 2021 at 21:05:14 UTC, deadalnix wrote:

>. 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...

9000 upvotes on this

On 02.03.21 22:05, deadalnix wrote:
> I think it is hard too argue that D doesn't have enough feature at this time.

OTOH, there is no pattern matching, in particular you can't pattern match tuples. Therefore, it is also very hard to argue that D is feature-complete. (Has it skipped leg day?)

On Monday, 8 March 2021 at 11:01:17 UTC, Timon Gehr wrote:
> On 02.03.21 22:05, deadalnix wrote:
>> I think it is hard too argue that D doesn't have enough feature at this time.
>
> OTOH, there is no pattern matching, in particular you can't pattern match tuples. Therefore, it is also very hard to argue that D is feature-complete. (Has it skipped leg day?)

While pattern matching would be nice, I place soundness above it. Plus, if you look at the SDC codebase for instance, you'll see that you can go pretty far as a library.

On Monday, 8 March 2021 at 15:39:52 UTC, deadalnix wrote:
> On Monday, 8 March 2021 at 11:01:17 UTC, Timon Gehr wrote:
>> On 02.03.21 22:05, deadalnix wrote:
>>> I think it is hard too argue that D doesn't have enough feature at this time.
>>
>> OTOH, there is no pattern matching, in particular you can't pattern match tuples. Therefore, it is also very hard to argue that D is feature-complete. (Has it skipped leg day?)
>
> While pattern matching would be nice, I place soundness above it. Plus, if you look at the SDC codebase for instance, you'll see that you can go pretty far as a library.

Oh, have you begun working on SDC again? ☀️

On 08.03.21 16:39, deadalnix wrote:
> On Monday, 8 March 2021 at 11:01:17 UTC, Timon Gehr wrote:
>> On 02.03.21 22:05, deadalnix wrote:
>>> I think it is hard too argue that D doesn't have enough feature at this time.
>>
>> OTOH, there is no pattern matching, in particular you can't pattern match tuples. Therefore, it is also very hard to argue that D is feature-complete. (Has it skipped leg day?)
> 
> While pattern matching would be nice, I place soundness above it.

For me it's not even a close contender. There's no soundness now and soundness is much harder to achieve than (or even without) obvious fundamental features. In comparison, soundness almost seems like a lost battle at this point.

> Plus, if you look at the SDC codebase for instance, you'll see that you can go pretty far as a library.


auto firstThingSecondThing=query!((ref foo)=>tuple(foo.a, foo.b))(data);
auto firstThing=firstThingSecondThing[0], secondThing=firstThingSecondThing[1];

Huge pain.


auto (firstThing,secondThing)=query!((ref foo)=>(foo.a, foo.b))(data);

Much better.

Whatever string mixin hack you can come up with is not good enough.