Is there an intention to 'finish' D2?

Thu Nov 18 09:38:09 UTC 2021

On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq wrote:
> On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:
>> On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:
>>> Is there a set of features that, when fully working, will 
>>> mean that D2 is now finished? Or will it forever be in a 
>>> state of ongoing feature development?
>>>
>
>> Time will tell.
>>
>
> I have a feeling that half the people in this forum are 
> thinking 'Are you trolling me, D2 was finished a decade ago', 
> and the other half are thinking it's a non-question. Allow me 
> to elaborate. I'm an occasional user of D since may years ago, 
> a D supporter. I'd love to see it become more well known and 
> used.
>
> I have now reached a stage in my career where I have a 
> significant influence on what languages are being used in a 
> commercial environment - and sometimes for large corporates. I 
> understand what it takes to make a large commercial application 
> succeed, to be maintainable, to have a sustainable future.
>
> With that user base in mind, probably the largest constituency 
> of developers that D could hope to reach, there are some 
> requirements, that I see D currently falling down on. I've just 
> been an observer of D for the last few years but that is the 
> case for nearly everyone in my position. I'm waiting for these 
> major DIPs and -preview this and that to settle back down to 
> Earth. I don't want to be having to work around **any** half 
> baked features, I don't have time. E.g. I want it to be clearly 
> defined how to implement and use ranges (from an observers POV 
> it feels like this question has never been properly answered, I 
> asked it many years ago and still it seems to be in motion).
>
> 'Finishing' D2 doesn't mean that feature development stops. It 
> means that the community makes a concerted attempt to make 
> **everything** work well that is claimed to work well, at least 
> make it work to a spec. Pin this fully working feature set to a 
> named long term supported version.
>
> It feels to this observer that there is not even a known list 
> of features that will one day work fully, and on which 
> platforms that will be done for. Until that is the case, I 
> cannot base my plans on D in a commercial environment.
>
> I believe that Walter et al. don't think that the user base I 
> am talking about, corporate application developers, are their 
> target audience. They have some other 'system' developers in 
> mind. That's fine with me! This post simply serves to point out 
> to the rest of the community why this particular group remain 
> waiting in the wings.

Disclaimer: Despite saying 'we' a few times, I do *not* speak for 
Funkwerk. All opinions are my own.

Offering a different take, that may be compatible with yours:

At Funkwerk, we use D in production, doing high-throughput 
backend work. (By cycle mostly JSON encoding/decoding, to be 
honest.) I want to be clear that if we ever switch to another 
language, it will almost certainly *not* be because D changes too 
fast or is too unstable, but because it changes too *slow* and is 
too set in its ways.

Barring breaking issues, we roll out compiler updates maybe every 
three major versions or so. This then takes a few months to 
propagate through all our services. However, especially in the 
last few versions, we've rarely had regression issues from DMD 
upgrades. I'd estimate the time spent on reporting or fixing 
compiler regressions as one or two developer-weeks in total 
across, uh, *checks* ~400kloc just for services that are at DMD 
2.09*, ie. reasonably recent and actively maintained. Time to get 
rid of deprecations is about that high again. In comparison, 
whenever we stumble on a novel compiler bug, that eats away 
another half-day or so from dustmiting. And it's not like we 
don't use the language to its fullest - as pointed out in 
previous dconfs, we use ranges very heavily (almost to the 
exclusion of imperative code) to enable a functional style, and 
boilerplate/serialized on github demonstrate that we aren't 
afraid of templates either. And yet, every time we upgrade, we 
maybe get a few instances of deprecations per service, that are 
easily fixed (maybe that we even pushed for), a few instances of 
regressions across the entire codebase, usually resulting in 
compile errors, extremely rarely in code errors, and not much 
change otherwise.

However, there is also time taken to work around language 
deficiencies. This is mostly not a big issue, and it's hard to 
quantify, but purely as a feeling I wouldn't put it as much lower 
than the previous issues. And there are things that should work 
but that we don't even attempt anymore, or only with great 
trepidation, such as marking data structures as immutable, due to 
language limitations with reassignment. (At least I got 
rebindable deployed internally, fingers crossed.)

I once said to a colleague that the process of learning D 
consists almost entirely, by time, of what *not* to do - what 
sort of things the language is happy about, what it only lets you 
get away with grudgingly, and what it will punish you for. Though 
some of the most severe gotchas have gotten fixed, I stand by 
this still.

All our issues with the language are documented and well-known in 
the community. D is efficient and we're all comfortable with it, 
but it's not like we're married to it; our microservice 
architecture does allow us to experiment with different 
frameworks for service development. As such, if we ever switch 
away from D, it will be because we've found something better - 
ie. because D was moving too slow to keep up with language 
improvements, not because it was moving so fast that it 
overwhelmed us. At present, I do not see that as a credible 
risk.On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq 
wrote:
> On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:
>> On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:
>>> Is there a set of features that, when fully working, will 
>>> mean that D2 is now finished? Or will it forever be in a 
>>> state of ongoing feature development?
>>>
>
>> Time will tell.
>>
>
> I have a feeling that half the people in this forum are 
> thinking 'Are you trolling me, D2 was finished a decade ago', 
> and the other half are thinking it's a non-question. Allow me 
> to elaborate. I'm an occasional user of D since may years ago, 
> a D supporter. I'd love to see it become more well known and 
> used.
>
> I have now reached a stage in my career where I have a 
> significant influence on what languages are being used in a 
> commercial environment - and sometimes for large corporates. I 
> understand what it takes to make a large commercial application 
> succeed, to be maintainable, to have a sustainable future.
>
> With that user base in mind, probably the largest constituency 
> of developers that D could hope to reach, there are some 
> requirements, that I see D currently falling down on. I've just 
> been an observer of D for the last few years but that is the 
> case for nearly everyone in my position. I'm waiting for these 
> major DIPs and -preview this and that to settle back down to 
> Earth. I don't want to be having to work around **any** half 
> baked features, I don't have time. E.g. I want it to be clearly 
> defined how to implement and use ranges (from an observers POV 
> it feels like this question has never been properly answered, I 
> asked it many years ago and still it seems to be in motion).
>
> 'Finishing' D2 doesn't mean that feature development stops. It 
> means that the community makes a concerted attempt to make 
> **everything** work well that is claimed to work well, at least 
> make it work to a spec. Pin this fully working feature set to a 
> named long term supported version.
>
> It feels to this observer that there is not even a known list 
> of features that will one day work fully, and on which 
> platforms that will be done for. Until that is the case, I 
> cannot base my plans on D in a commercial environment.
>
> I believe that Walter et al. don't think that the user base I 
> am talking about, corporate application developers, are their 
> target audience. They have some other 'system' developers in 
> mind. That's fine with me! This post simply serves to point out 
> to the rest of the community why this particular group remain 
> waiting in the wings.

Offering a different take, that may be compatible with yours:

At Funkwerk, we use D in production, doing high-throughput 
backend work. (By cycle mostly JSON encoding/decoding, to be 
honest.) I want to be clear that if we ever switch to another 
language, it will almost certainly *not* be because D changes too 
fast or is too unstable, but because it changes too *slow* and is 
too set in its ways.

Barring breaking issues, we roll out compiler updates maybe every 
three major versions or so. This then takes a few months to 
propagate through all our services. However, especially in the 
last few versions, we've rarely had regression issues from DMD 
upgrades. I'd estimate the time spent on reporting or fixing 
compiler regressions as one or two developer-weeks in total 
across, uh, *checks* ~400kloc just for services that are at DMD 
2.09*, ie. reasonably recent and actively maintained. Time to get 
rid of deprecations is about that high again. In comparison, 
whenever we stumble on a novel compiler bug, that eats away 
another half-day or so from dustmiting. And it's not like we 
don't use the language to its fullest - as pointed out in 
previous dconfs, we use ranges very heavily (almost to the 
exclusion of imperative code) to enable a functional style, and 
boilerplate/serialized on github demonstrate that we aren't 
afraid of templates either. And yet, every time we upgrade, we 
maybe get a few instances of deprecations per service, that are 
easily fixed (maybe that we even pushed for), a few instances of 
regressions across the entire codebase, usually resulting in 
compile errors, extremely rarely in code errors, and not much 
change otherwise.

However, there is also time taken to work around language 
deficiencies. This is mostly not a big issue, and it's hard to 
quantify, but purely as a feeling I wouldn't put it as much lower 
than the previous issues. And there are things that should work 
but that we don't even attempt anymore, or only with great 
trepidation, such as marking data structures as immutable, due to 
language limitations with reassignment. (At least I got 
rebindable deployed internally, fingers crossed.)

I once said to a colleague that the process of learning D 
consists almost entirely, by time, of what *not* to do - what 
sort of things the language is happy about, what it only lets you 
get away with grudgingly, and what it will punish you for. Though 
some of the most severe gotchas have gotten fixed, I stand by 
this still.

All our issues with the language are documented and well-known in 
the community. D is efficient and we're all comfortable with it, 
but it's not like we're married to it; our microservice 
architecture does allow us to experiment with different 
frameworks for service development. As such, if we ever switch 
away from D, it will be because we've found something better - 
ie. because D was moving too slow to keep up with language 
improvements, not because it was moving so fast that it 
overwhelmed us. At present, I do not see that as a credible risk.

*On the other hand,* we also don't really use DIP features. I 
think maybe this is a communications problem. In my experience, 
the parts of D that are released and have been used for a few 
major versions tend to be very stable and hard to change. So 
people see all the cool new things, @live, DIP1000, ImportC, and 
think that the language is still in flux. But the core 
functionality of the language, ranges, templates, constness etc. 
is and has been incredibly stable even since D1, so if you just 
ignore the rapidly mutating fringe you'll get exactly what you 
want - a stable, even too stable, subset.