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?

We all know that properly finishing and polishing the last 10% of a software project takes 90% of the time. Is there a timescale for that? What platforms will it support?

On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

There are too few major developers.

On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

No, but mark my words there will be 15 new attributes before any of it is finished.

On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

As the ongoing threads to reboot the language memory model prove, it is doomed to be in a state of ongoing feature development.

On Tuesday, 16 November 2021 at 12:25:19 UTC, Paulo Pinto wrote:

Maybe, but D doesn't really have a memory model. So it is more about getting one than rebooting…

On Tuesday, 16 November 2021 at 08:55:27 UTC, Abdulhaq wrote:

Time will tell.

Currently pretty much is happening and with the stdv2 etc. So my sense it that D2 will be in pretty stable soon. And I don't know if the stdv2 will in the long run enable D3 or not but it's interesting that we're starting at least.

On Tuesday, 16 November 2021 at 13:18:54 UTC, Imperatorn wrote:

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.

On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq wrote:

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:

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.

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.

On Thursday, 18 November 2021 at 09:38:09 UTC, FeepingCreature wrote:

Er, please ignore the top part of that, somehow I got a previous revision of the message copypasted on top. What the heck. Mods, if you delete that I can repost it better?

On Thursday, 18 November 2021 at 08:44:57 UTC, Abdulhaq wrote:

I dont think having many users that have no real interest in the language is an advantage at this point, to be honest. It makes changes more difficult.

I feel the opposite, but I am happy if you are right.