www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Future of D

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
We are merging companies and our new product will be integrated 
in all our devices.

The test round is 50 devices, just to make sure D really works 
(it will be a kind of status-service that checks various 
parameters of the device and reports them).

The plan is between 50 thousand (realistic) to 100 thousand 
(optimistic) devices each year.

However, we are becoming unsure if D is really an option for us 
given the response we got trying to making almost the smallest 
change imaginable to phobos (changing a single word).

The product manager (who has a programming background) is very 
concerned.

Can we count on that if we find an issue with D that it will be 
taken care of? And if so, how, and by whom? That it will not be 
silently ignored for years? How can we safeguard against that?

Is the recommended course of action to fork dmd, druntime and 
phobos and have a completely parallel version of D, a bit like 
Weka? Is that what companies normally do?

What is the recommended approach?

Thanks!

PS. This should not be a discussion about some specific PR etc, 
but a general discussion about how companies should view this. DS.
Oct 29 2023
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 However, we are becoming unsure if D is really an option for us 
 given the response we got trying to making almost the smallest 
 change imaginable to phobos (changing a single word).

 The product manager (who has a programming background) is very 
 concerned.

 Can we count on that if we find an issue with D that it will be 
 taken care of? And if so, how, and by whom? That it will not be 
 silently ignored for years? How can we safeguard against that?


It sounds like you should probably get in touch with the D 
Language Foundation about this. Mike Parker, who posts the DLF 
meeting updates in the Announce forum, should be able to connect 
you with the right people.
Oct 29 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 12:58:28 UTC, Paul Backus wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 However, we are becoming unsure if D is really an option for 
 us given the response we got trying to making almost the 
 smallest change imaginable to phobos (changing a single word).

 The product manager (who has a programming background) is very 
 concerned.

 Can we count on that if we find an issue with D that it will 
 be taken care of? And if so, how, and by whom? That it will 
 not be silently ignored for years? How can we safeguard 
 against that?


 It sounds like you should probably get in touch with the D 
 Language Foundation about this. Mike Parker, who posts the DLF 
 meeting updates in the Announce forum, should be able to 
 connect you with the right people.


Ok, we will contact him and see what can be done. Thanks!
Oct 29 2023
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 12:58:28 UTC, Paul Backus wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 However, we are becoming unsure if D is really an option for 
 us given the response we got trying to making almost the 
 smallest change imaginable to phobos (changing a single word).

 The product manager (who has a programming background) is very 
 concerned.

 Can we count on that if we find an issue with D that it will 
 be taken care of? And if so, how, and by whom? That it will 
 not be silently ignored for years? How can we safeguard 
 against that?


 It sounds like you should probably get in touch with the D 
 Language Foundation about this. Mike Parker, who posts the DLF 
 meeting updates in the Announce forum, should be able to 
 connect you with the right people.


Thanks, I got in contact with him now 👍
Oct 29 2023
prev sibling next sibling parent reply Abdulhaq <alynch4048 gmail.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 We are merging companies and our new product will be integrated 
 in all our devices.



 However, we are becoming unsure if D is really an option for us 
 given the response we got trying to making almost the smallest 
 change imaginable to phobos (changing a single word).

 The product manager (who has a programming background) is very 
 concerned.


I can't think of any 'serious' programming language where the 
maintainers will modify the core libraries just to accommodate a 
relatively small user.


 Can we count on that if we find an issue with D that it will be 
 taken care of? And if so, how, and by whom? That it will not be 
 silently ignored for years? How can we safeguard against that?


It's clearly a business decision that is heavily dependent on 
what you need the language ecosystem to do. 9k lines of 
application code and 1k of drivers? Just use C++ and be done with 
it.

300k LOC with wide-ranging algorithms that need to be coded up in 
2 years and supported for just 3 yrs before a rewrite? x86? Use D.

200k LOC with 20 yrs support? C++.

80k LOC embedded that depends on libraries written by a couple of 
D hobbyists? Ehhh, maybe not.


 Is the recommended course of action to fork dmd, druntime and 
 phobos and have a completely parallel version of D, a bit like 
 Weka? Is that what companies normally do?


Sounds like you're not a big business. Concentrate on your core 
competence, which isn't writing compilers.
Oct 29 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 16:34:25 UTC, Abdulhaq wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 We are merging companies and our new product will be 
 integrated in all our devices.




Can you explain why you responded to this?

It doesn't help anyone really and also doesn't give any insight 
into anything.

All is does is say "use C++". But I asked in a D-forum.
Oct 29 2023
parent Abdulhaq <alynch4048 gmail.com> writes:
On Sunday, 29 October 2023 at 16:38:22 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 16:34:25 UTC, Abdulhaq wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 We are merging companies and our new product will be 
 integrated in all our devices.




 Can you explain why you responded to this?


Because you asked the question and I have a useful answer so I 
shared it.


 It doesn't help anyone really and also doesn't give any insight 
 into anything.


You're not in a good mood, are you.


 All is does is say "use C++". But I asked in a D-forum.


I proposed a scenario where you would use D. Anyway, if D is your 
only choice then fine, choose D. Simples.
Oct 29 2023
prev sibling next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 We are merging companies and our new product will be integrated 
 in all our devices.

 The test round is 50 devices, just to make sure D really works 
 (it will be a kind of status-service that checks various 
 parameters of the device and reports them).

 The plan is between 50 thousand (realistic) to 100 thousand 
 (optimistic) devices each year.

 However, we are becoming unsure if D is really an option for us 
 given the response we got trying to making almost the smallest 
 change imaginable to phobos (changing a single word).

 The product manager (who has a programming background) is very 
 concerned.

 Can we count on that if we find an issue with D that it will be 
 taken care of? And if so, how, and by whom? That it will not be 
 silently ignored for years? How can we safeguard against that?

 Is the recommended course of action to fork dmd, druntime and 
 phobos and have a completely parallel version of D, a bit like 
 Weka? Is that what companies normally do?

 What is the recommended approach?

 Thanks!

 PS. This should not be a discussion about some specific PR etc, 
 but a general discussion about how companies should view this. 
 DS.


I can testify that D is industry-friendly, more than lot of other 
languages IMHO.

Your company has a better chance here to be assisted for a 
specific problem that may arise impacting your product than in 
other languages.

Just a few weeks ago, I raised my hand for a regression impacting 
our codebase, and all the team was really responsive, with a 
quick workaround and then a pull request closing the bug, landed 
in the really next release.

We are very satisfied about the language and the care about 
industry, and it's powering our commercial offer from the bottom 
to the top.

D is a Five Stars Choice!

Paolo, CEO DeepGlance
Oct 29 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 16:39:15 UTC, Paolo Invernizzi 
wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 [...]


 I can testify that D is industry-friendly, more than lot of 
 other languages IMHO.

 Your company has a better chance here to be assisted for a 
 specific problem that may arise impacting your product than in 
 other languages.

 Just a few weeks ago, I raised my hand for a regression 
 impacting our codebase, and all the team was really responsive, 
 with a quick workaround and then a pull request closing the 
 bug, landed in the really next release.

 We are very satisfied about the language and the care about 
 industry, and it's powering our commercial offer from the 
 bottom to the top.

 D is a Five Stars Choice!

 Paolo, CEO DeepGlance


That's very good to hear!

Thanks for your input
Oct 29 2023
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 The plan is between 50 thousand (realistic) to 100 thousand 
 (optimistic) devices each year.

 However, we are becoming unsure if D is really an option for us



I'd probably consider hiring compiler devs who are doing 
something interesting but grumpy with the management and making a 
d subset compiler that you control if you actually of a size 
large enough to justify it
Oct 29 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 16:39:28 UTC, monkyyy wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 The plan is between 50 thousand (realistic) to 100 thousand 
 (optimistic) devices each year.

 However, we are becoming unsure if D is really an option for us



 I'd probably consider hiring compiler devs who are doing 
 something interesting but grumpy with the management and making 
 a d subset compiler that you control if you actually of a size 
 large enough to justify it


Maybe, but it would be best if we didn't have to and could stay 
mainline D as long as possible. I want to hear other peoples 
experiences with this for comparison.
Oct 29 2023
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 29 October 2023 at 16:46:02 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 16:39:28 UTC, monkyyy wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 The plan is between 50 thousand (realistic) to 100 thousand 
 (optimistic) devices each year.

 However, we are becoming unsure if D is really an option for 
 us



 I'd probably consider hiring compiler devs who are doing 
 something interesting but grumpy with the management and 
 making a d subset compiler that you control if you actually of 
 a size large enough to justify it


 Maybe, but it would be best if we didn't have to and could stay 
 mainline D as long as possible. I want to hear other peoples 
 experiences with this for comparison.


In my experience, only 1 bug report of mine has ever been 
addressed; and the drama this week was patches written 6 years 
ago.


 Can we count on that if we find an issue with D that it will be 
 taken care of?


so the answer is just no; you should not expect d to change 
meaningfully ever. If you want a foundation to base a lot of 
people's livelihood on you should day 1 plan to build that 
foundation in parallel with whatever product you making so you 
have the talent on hand and meaningful control over the outcomes.
Oct 29 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 17:05:10 UTC, monkyyy wrote:

 On Sunday, 29 October 2023 at 16:46:02 UTC, Imperatorn wrote:

 [...]


 In my experience, only 1 bug report of mine has ever been 
 addressed; and the drama this week was patches written 6 years 
 ago.


 [...]


 so the answer is just no; you should not expect d to change 
 meaningfully ever. If you want a foundation to base a lot of 
 people's livelihood on you should day 1 plan to build that 
 foundation in parallel with whatever product you making so you 
 have the talent on hand and meaningful control over the 
 outcomes.


Hmm. I will take your points into consideration. Thanks

I'm making a list of pros and cons.
Oct 29 2023
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 Is the recommended course of action to fork dmd, druntime and 
 phobos and have a completely parallel version of D, a bit like


That is the only future of D unfortunately, that someone with a 
little vision of the future continues with D.

Don't wait for something to happen with the D foundation because 
you will probably retire before that.

There are other languages but not as nice as D in this particular 
niche which is really sad.
Oct 29 2023
next sibling parent reply Abdulhaq <alynch4048 gmail.com> writes:
On Sunday, 29 October 2023 at 17:20:36 UTC, IGotD- wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 Is the recommended course of action to fork dmd, druntime and 
 phobos and have a completely parallel version of D, a bit like


 That is the only future of D unfortunately, that someone with a 
 little vision of the future continues with D.

 Don't wait for something to happen with the D foundation 
 because you will probably retire before that.

 There are other languages but not as nice as D in this 
 particular niche which is really sad.


Choosing a programming ecosystem for a business is a bit like a 
marriage, and if peoples' livelihoods depend on it then the 
decision should be taken seriously and objectively, looking at it 
from many angles. Having fun programming in D is important but 
there are many other factors.

Even businesses the size of Meta will think twice before choosing 
a language if if it means having to fork the language and 
maintain it. When smaller businesses get sucked into an area 
which is not in their core competence then it often leads to 
major problems and downstream regrets after the initial shine 
wears off.

D is great but a business decision to use it should be based on 
sound principles, not fanboi-isms. For me, if you need to fork D 
to use it for a business, that's a red flag.
Oct 29 2023
parent reply IGotD- <nise nise.com> writes:
On Sunday, 29 October 2023 at 17:29:51 UTC, Abdulhaq wrote:

 D is great but a business decision to use it should be based on 
 sound principles, not fanboi-isms. For me, if you need to fork 
 D to use it for a business, that's a red flag.


Why? I would rather say that forking a programming language in 
order to tailor it for ones need is a serious commitment.
Oct 29 2023
parent reply Abdulhaq <alynch4048 gmail.com> writes:
On Sunday, 29 October 2023 at 18:00:13 UTC, IGotD- wrote:

 On Sunday, 29 October 2023 at 17:29:51 UTC, Abdulhaq wrote:

 D is great but a business decision to use it should be based 
 on sound principles, not fanboi-isms. For me, if you need to 
 fork D to use it for a business, that's a red flag.


 Why? I would rather say that forking a programming language in 
 order to tailor it for ones need is a serious commitment.


Yes that's a fair comment. What I mean is that for most 
businesses, the choice between D and e.g. C++ is best understood 
in terms of risk /reward.

C++ is the low risk option, for a typical business, because it 
will still be around in 20 years, it will be well maintained, you 
will always be able to find a pool of developers who can maintain 
your code, it will link and compile with thousands of industry 
standard libraries, frameworks, protocols, hardware platforms.

So D is higher risk in that you may find yourself having to spend 
time (and much money) coding up your own libraries and hardware 
support. In 10 years time you might struggle to find D 
developers. However, the reward with D is that you can achieve 
the required functionality, over the next few years, much more 
quickly (i.e. more cheaply) than with C++.

So you choose D if you want to code up a well understood set of 
algorithms/functionalities on known platforms and you want to do 
it quickly/cheaply, and you know that D can provide all that you 
need.

You choose C++ for long term support, a huge breadth of 
platforms, some of which are future platforms you don't yet know 
about, and general maintenance ability over the years.

To finally answer your question, maintaining a compiler/ecosystem 
is a significant cost overhead the reduces the rewards of D to 
such an extent that it is normally wiser to choose C++.
Oct 29 2023
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:

 
 C++ is the low risk option, for a typical business


That seems dubious, theres also talk of c++ dying, c++ has super 
long compile times and maybe you use a feature that steps onto a 
landmine of those hours compiling. And as hard as making a 
compiler with your subset of d is, making a compiler for c++ 
seems all that much worse.
Oct 29 2023
next sibling parent Abdulhaq <alynch4048 gmail.com> writes:
On Sunday, 29 October 2023 at 18:20:40 UTC, monkyyy wrote:

 On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:

 
 C++ is the low risk option, for a typical business


 That seems dubious, theres also talk of c++ dying, c++ has 
 super long compile times and maybe you use a feature that steps 
 onto a landmine of those hours compiling. And as hard as making 
 a compiler with your subset of d is, making a compiler for c++ 
 seems all that much worse.


Yes reasonable people can certainly differ on this, but the vast 
majority of businesses that are using C++ do not need to maintain 
a C++ compiler/ecosystem. We are considering a business that 
thinks it would need to maintain a D compiler/ecosystem if it 
were to choose D for their business.
Oct 29 2023
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 18:20:40 UTC, monkyyy wrote:

 On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:

 
 C++ is the low risk option, for a typical business


 That seems dubious, theres also talk of c++ dying, c++ has 
 super long compile times and maybe you use a feature that steps 
 onto a landmine of those hours compiling. And as hard as making 
 a compiler with your subset of d is, making a compiler for c++ 
 seems all that much worse.


Yes, we don't consider C++ a safe choice.
Oct 29 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:


 C++ is the low risk option, for a typical business, because it 
 will still be around in 20 years, it will be well maintained, 
 you will always be able to find a pool of developers who can 
 maintain your code, it will link and compile with thousands of 
 industry standard libraries, frameworks, protocols, hardware 
 platforms.

 So D is higher risk in that you may find yourself having to 
 spend time (and much money) coding up your own libraries and 
 hardware support. In 10 years time you might struggle to find D 
 developers. However, the reward with D is that you can achieve 
 the required functionality, over the next few years, much more 
 quickly (i.e. more cheaply) than with C++.


There's a lot of speculation in those two paragraphs. The risk 
with D (using your definition of risk) is non-zero, but not much 
greater than zero. If nobody is using D in ten years, which is a 
very low probability scenario, you can compile the existing D 
codebase and call it from C++ just like you'd call any C code.

While C++ will be around in 20 years, the cost of maintaining the 
code could be high enough that it's not worth it. A real danger 
with C++ is that it's not the first choice of new developers. In 
20 years you might be competing for talent with the finance 
industry. That's a battle few companies are going to win.

You're also ignoring everything that takes place from now until 
2043. Higher cost of code development and maintenance is quite a 
liability to ignore as "not a risk".
Oct 29 2023
parent Abdulhaq <alynch4048 gmail.com> writes:
On Sunday, 29 October 2023 at 18:33:05 UTC, bachmeier wrote:

 On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:



 There's a lot of speculation in those two paragraphs. The risk 
 with D (using your definition of risk) is non-zero, but not 
 much greater than zero. If nobody is using D in ten years, 
 which is a very low probability scenario, you can compile the 
 existing D codebase and call it from C++ just like you'd call 
 any C code.

 While C++ will be around in 20 years, the cost of maintaining 
 the code could be high enough that it's not worth it. A real 
 danger with C++ is that it's not the first choice of new 
 developers. In 20 years you might be competing for talent with 
 the finance industry. That's a battle few companies are going 
 to win.

 You're also ignoring everything that takes place from now until 
 2043. Higher cost of code development and maintenance is quite 
 a liability to ignore as "not a risk".


Yes it _is_ a lot of speculation, but I think these are the sorts 
of issues that need to be considered when making these decisions. 
There are so many real variables that it all just amounts to 
broad guesses, but better than nothing. And each person will 
weigh the factors according to their own experiences.
Oct 29 2023
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 17:20:36 UTC, IGotD- wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 Is the recommended course of action to fork dmd, druntime and 
 phobos and have a completely parallel version of D, a bit like


 That is the only future of D unfortunately, that someone with a 
 little vision of the future continues with D.

 Don't wait for something to happen with the D foundation 
 because you will probably retire before that.

 There are other languages but not as nice as D in this 
 particular niche which is really sad.


Can you explain your standpoint? Why do you think so?

Thanks
Oct 29 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2023 5:54 AM, Imperatorn wrote:

 However, we are becoming unsure if D is really an option for us given the 
 response we got trying to making almost the smallest change imaginable to
phobos 
 (changing a single word).


What is that change?
Oct 29 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I'm pretty certain it was: https://github.com/dlang/phobos/pull/8832
Oct 29 2023
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 18:20:28 UTC, Walter Bright wrote:

 On 10/29/2023 5:54 AM, Imperatorn wrote:

 However, we are becoming unsure if D is really an option for 
 us given the response we got trying to making almost the 
 smallest change imaginable to phobos (changing a single word).


 What is that change?


Nevermind, it was just exposing the TaskStatus enum. But it 
turned out that the property taskStatus that contained the value 
for it was not supposed to be exposed either, and the 
AbstractTask was just a "temporary" fix back in 2011, and also 
taskStatus was being accessed by alias this.

A bug report has been created for it by schveiguy since I can't 
access bugzilla because of an intermittent DNS problem.

Next step is to provide a safe way to get the task status after 
the pr has been merged.
Oct 29 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2023 11:38 AM, Imperatorn wrote:

 A bug report has been created for it by schveiguy since I can't access
bugzilla 
 because of an intermittent DNS problem.


And a PR:

https://github.com/dlang/phobos/pull/8834



 Next step is to provide a safe way to get the task status after the pr has
been 
 merged.
Oct 29 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 20:39:19 UTC, Walter Bright wrote:

 On 10/29/2023 11:38 AM, Imperatorn wrote:

 A bug report has been created for it by schveiguy since I 
 can't access bugzilla because of an intermittent DNS problem.


 And a PR:

 https://github.com/dlang/phobos/pull/8834



 Next step is to provide a safe way to get the task status 
 after the pr has been merged.




Yes, it's great to see. Now the next step is to improve it so 
that you can get the task status safely 😎
Oct 29 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 29, 2023 3:03:00 PM MDT Imperatorn via Digitalmars-d wrote:

 On Sunday, 29 October 2023 at 20:39:19 UTC, Walter Bright wrote:

 On 10/29/2023 11:38 AM, Imperatorn wrote:

 A bug report has been created for it by schveiguy since I
 can't access bugzilla because of an intermittent DNS problem.


 And a PR:

 https://github.com/dlang/phobos/pull/8834


 Next step is to provide a safe way to get the task status
 after the pr has been merged.




 Yes, it's great to see. Now the next step is to improve it so
 that you can get the task status safely 😎


You have yet to explain why that information should be made public. Even if
you can get the task status without breaking thread-safety, the information
is still likely to be out-of-date by the time you actually try to do
anything based on it, because once you have the state information out of the
Task, that state information is no longer synchronized across threads. It's
just a copy of what the state was when the state was copied across threads.
So, actually making it possible to get the state information in a
thread-safe manner doesn't fix the problem that trying to do anything based
on that information involves race conditions.

And none of the functions on the Task are designed in such a way that it
really makes sense to call them or not based on whether a task has started
or not. The design of std.parallelism very purposefully only exposed the
status of whether the task is done or not, because that's really the only
actionable state information with the set of functions that it provides.

In general, trying to do anything based on whether the task has started or
not is going to be subject to race conditions unless what you're trying to
do is actually built into the Task like the *Force functions are.

So, the question is what problem are you trying to solve by making the task
status public? What does that enable that you cannot currently do without
that information?

If you have a good use case, then it may make sense to expose the state
information, but as was pointed out in your previous PR, exposing that state
information is likely to mislead programmers and risk causing them to write
code that has race conditions due to out-of-date state information - and no
one reviewing the PR saw how exposing that state information would actually
enable anything. So, please provide a use case where exposing that state
information actually enables something that you can't do without it.

- Jonathan M Davis
Oct 29 2023
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis 
wrote:

 On Sunday, October 29, 2023 3:03:00 PM MDT Imperatorn via 
 Digitalmars-d wrote:

 [...]


 You have yet to explain why that information should be made 
 public. Even if you can get the task status without breaking 
 thread-safety, the information is still likely to be 
 out-of-date by the time you actually try to do anything based 
 on it, because once you have the state information out of the 
 Task, that state information is no longer synchronized across 
 threads. It's just a copy of what the state was when the state 
 was copied across threads. So, actually making it possible to 
 get the state information in a thread-safe manner doesn't fix 
 the problem that trying to do anything based on that 
 information involves race conditions.

 [...]


Because it would be wonderful. I could use it to draw a rainbow 
on the screen.
Oct 29 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:


 Because it would be wonderful. I could use it to draw a rainbow 
 on the screen.


Everyone: Let's move any further discussion of string 
interpolation to a new thread. And let's please keep it focused 
on the topic at hand and dispense with the nonsense. Consider 
this thread closed.

Thanks.
Oct 30 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 30 October 2023 at 12:37:01 UTC, Mike Parker wrote:

 On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:


 Because it would be wonderful. I could use it to draw a 
 rainbow on the screen.


 Everyone: Let's move any further discussion of string 
 interpolation to a new thread. And let's please keep it focused 
 on the topic at hand and dispense with the nonsense. Consider 
 this thread closed.

 Thanks.


Maybe wrong thread, Mike? This one is not about string 
interpolation at all
Oct 30 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 12:45:42 UTC, Sergey wrote:

 On Monday, 30 October 2023 at 12:37:01 UTC, Mike Parker wrote:

 On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:


 Because it would be wonderful. I could use it to draw a 
 rainbow on the screen.


 Everyone: Let's move any further discussion of string 
 interpolation to a new thread. And let's please keep it 
 focused on the topic at hand and dispense with the nonsense. 
 Consider this thread closed.

 Thanks.


 Maybe wrong thread, Mike? This one is not about string 
 interpolation at all


I think it was just a wrong post from the other thread
Oct 30 2023
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 30 October 2023 at 12:45:42 UTC, Sergey wrote:


 Maybe wrong thread, Mike? This one is not about string 
 interpolation at all


Yes, I took a wrong turn.
Oct 30 2023
prev sibling next sibling parent reply duckchess <duckchess chess.com> writes:
On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis 
 wrote:

 [...]


 Because it would be wonderful. I could use it to draw a rainbow 
 on the screen.


my advice: don't use D in your company. no one will help you any 
more with your problems the way you talk to them.
Oct 30 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 13:21:59 UTC, duckchess wrote:

 On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis 
 wrote:

 [...]


 Because it would be wonderful. I could use it to draw a 
 rainbow on the screen.


 my advice: don't use D in your company. no one will help you 
 any more with your problems the way you talk to them.


?
Oct 30 2023
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Sometimes, if we knew what problem you're faced with, we can find the best 
solution. Help us help you!
Oct 30 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 17:27:27 UTC, Walter Bright wrote:

 Sometimes, if we knew what problem you're faced with, we can 
 find the best solution. Help us help you!


That's good to hear. Since D will be running on at least 50 
thousand devices within a year, it's kind of important.

It will be a very small project, that's why I feel confident. 
Just some things that are lacking, but no big deal, we can work 
around them.

We have compared 20 languages before coming to D, Nim, Go and C++ 
included. Our analysis showed that even though D is a smaller 
language, its learning curve is not steep and if you don't do 
weird stuff, the code is comprehensible and maintainable.

I have already put 3 packages on dub just to accomodate some 
missing features. dub works well and supports cross-compilation, 
which has been very easy to do for us.

Both from x64 Windows to aarch64 Linux and from x64 Linux to x64 
Windows.

D is easy to learn, yet powerful, while also being efficient.

For example, take a look at the benchmark I, schveiguy and Sergi 
took part in:
https://github.com/jinyus/related_post_gen

We hope that D will continue to flourish and that we will be able 
to use it in the future
Oct 30 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2023 11:56 AM, Imperatorn wrote:

 That's good to hear. Since D will be running on at least 50 thousand devices 
 within a year, it's kind of important.
 
 It will be a very small project, that's why I feel confident. Just some things 
 that are lacking, but no big deal, we can work around them.
 
 We have compared 20 languages before coming to D, Nim, Go and C++ included.
Our 
 analysis showed that even though D is a smaller language, its learning curve
is 
 not steep and if you don't do weird stuff, the code is comprehensible and 
 maintainable.
 
 I have already put 3 packages on dub just to accomodate some missing features. 
 dub works well and supports cross-compilation, which has been very easy to do 
 for us.
 
 Both from x64 Windows to aarch64 Linux and from x64 Linux to x64 Windows.
 
 D is easy to learn, yet powerful, while also being efficient.
 
 For example, take a look at the benchmark I, schveiguy and Sergi took part in:
 https://github.com/jinyus/related_post_gen
 
 We hope that D will continue to flourish and that we will be able to use it in 
 the future


Thanks for the kind words and contributions! I appreciate them.

I especially enjoy you writing that D code is comprehensible and maintainable, 
as that has been a major goal of the language from the beginning. In many
cases, 
D has deliberately dialed down the power of some constructs that inevitably
lead 
to incomprehensible code in other languages. I know these decisions are 
sometimes controversial.

Of course, it is still possible to write incomprehensible tangles of code, but 
if we can make it both pointless and harder, that's a win.
Oct 31 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright 
wrote:

 On 10/30/2023 11:56 AM, Imperatorn wrote:

 That's good to hear. Since D will be running on at least 50 
 thousand devices within a year, it's kind of important.
 
 It will be a very small project, that's why I feel confident. 
 Just some things that are lacking, but no big deal, we can 
 work around them.
 
 We have compared 20 languages before coming to D, Nim, Go and 
 C++ included. Our analysis showed that even though D is a 
 smaller language, its learning curve is not steep and if you 
 don't do weird stuff, the code is comprehensible and 
 maintainable.
 
 I have already put 3 packages on dub just to accomodate some 
 missing features. dub works well and supports 
 cross-compilation, which has been very easy to do for us.
 
 Both from x64 Windows to aarch64 Linux and from x64 Linux to 
 x64 Windows.
 
 D is easy to learn, yet powerful, while also being efficient.
 
 For example, take a look at the benchmark I, schveiguy and 
 Sergi took part in:
 https://github.com/jinyus/related_post_gen
 
 We hope that D will continue to flourish and that we will be 
 able to use it in the future


 Thanks for the kind words and contributions! I appreciate them.


I have yet to find a language except D that:
- Compiles to native
- Is fast
- Allows for both low and high level constructions
- Is from the C-family
- Has a package manager
- Is production ready
- Is not Rust ;)
- Allows you to be productive (has GC, this is very important)
...


available for some targets.

The most important feature for me/us is productivity.

That's the metric we use if a language is good or bad basically.

It doesn't matter if you have the "best language in the world" if 
you can't make something with it, or it takes so long that you 
loose your train of thought just because you're fighting the 
language instead of solving the problem, it's not very useful.

In our opinion the main goal of a language L is to reduce the 
time it takes to transform an idea into comprehensible code, ie 
minimize L(idea).

This is a concept that does not have anything to do with 
familiarity of the language at hand, but rather, given language L 
with no prior knowledge of L, produce the output xyz, you get the 
idea.

Benchmarks on the web should include development time, not only 
execution time.

It will of course be unfair if a language is of a family that you 
already have some familiarity with, but not much if you are 
familiar with a multitude of families :)

For example, not knowing *anything* about Nim, I was productive 
very fast because many things were just intuitive. Same with D. 

syntax.

I can't say the same thing for Rust for example. Just a step back 
in terms of productivity with minimal gain in safety. And 
frankly, most errors are logical if you're doing things right, 
not memory related. I can't remember if I ever had a memory 

don't use pointers etc. And following MISRA guidelines + IAR 
C-STAT for example helps us when we *have* to write C. 
Unfortunately, you can't escape C yet, and I think we won't for 
years to come. Fortunately, I don't have to write C at the moment.

Don't use pointers, use the gc and be a good friend with the 
stack, goes a long way.

You don't need Rust to be a sane citizen of the programming world.

That's our current take on it anyway.
Nov 01 2023
prev sibling parent reply Olaf <erstaunlichinstinktiverfrosch muell.monster> writes:
On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright 
wrote:

 On 10/30/2023 11:56 AM, Imperatorn wrote:

 [snip]


 Thanks for the kind words and contributions! I appreciate them.

 [snip]


Wow. That's tough.

I very much respect your technical accomplishments and your many 
years of dedication.
However, I am deeply shocked to see insubstantial and 
disrespectful behavior rewarded with attention and goodwill from 
leadership.
At the same time, the morale of long-time and extremely capable 
contributors like Adam is being undermined by misrepresenting his 
proposals and imposing ever new hurdles.

It is a shame to destroy the potential of the language and the 
ecosystem so carelessly.

Olaf
Nov 01 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 1 November 2023 at 09:00:38 UTC, Olaf wrote:

 On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright 
 wrote:

 On 10/30/2023 11:56 AM, Imperatorn wrote:

 [snip]


 Thanks for the kind words and contributions! I appreciate them.

 [snip]


 Wow. That's tough.

 I very much respect your technical accomplishments and your 
 many years of dedication.
 However, I am deeply shocked to see insubstantial and 
 disrespectful behavior rewarded with attention and goodwill 
 from leadership.
 At the same time, the morale of long-time and extremely capable 
 contributors like Adam is being undermined by misrepresenting 
 his proposals and imposing ever new hurdles.

 It is a shame to destroy the potential of the language and the 
 ecosystem so carelessly.

 Olaf


Did you reply to the wrong post or in the wrong thread?
Nov 01 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 1 November 2023 at 11:23:11 UTC, Imperatorn wrote:

 On Wednesday, 1 November 2023 at 09:00:38 UTC, Olaf wrote:

 On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright 
 wrote:

 [...]


 Wow. That's tough.

 I very much respect your technical accomplishments and your 
 many years of dedication.
 However, I am deeply shocked to see insubstantial and 
 disrespectful behavior rewarded with attention and goodwill 
 from leadership.
 At the same time, the morale of long-time and extremely 
 capable contributors like Adam is being undermined by 
 misrepresenting his proposals and imposing ever new hurdles.

 It is a shame to destroy the potential of the language and the 
 ecosystem so carelessly.

 Olaf


 Did you reply to the wrong post or in the wrong thread?


What I mean is, why wouldn't Walter appreciate Adams work? I am 
of the impression he does.
Nov 01 2023
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis 
 wrote:

 [...]


 Because it would be wonderful. I could use it to draw a rainbow 
 on the screen.


This attitude won't help you.
Oct 30 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 17:47:33 UTC, Patrick Schluter 
wrote:

 On Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis 
 wrote:

 [...]


 Because it would be wonderful. I could use it to draw a 
 rainbow on the screen.


 This attitude won't help you.


Sure, but neither does not trying to understand a basic use case 


It's like asking why would you need printf, just use the debugger.

Sure, but sometimes printf can be kinda useful.

If you're not even *trying* to understand, how does it help 
anyone?

In a way it's a kind of "anti-help", since not only was no help 
given, but it also reduces the probability anyone with a similar 
use case will get help in the future.

If there was a "helpfulness-metric", it would decrease every time 
someone would ask a good question and get an "anti-help" answer.

So, over time, fewer questions would get asked, and of course if 
that happens it's kinda hard to answer them after a while, since 
it would reach zero.

Just because someone doesn't understand a use case doesn't mean 
millions of people are idiots, it might mean you simply don't see 
the value that those millions of people do, and therefore you 
don't understand it.

You just have to ask what is more likely.
Oct 30 2023
prev sibling parent reply Sergey <kornburn yandex.ru> writes:
On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis 
wrote:

 If you have a good use case, then it may make sense to expose 
 the state information, but as was pointed out in your previous 
 PR, exposing that state information is likely to mislead 
 programmers and risk causing them to write code that has race 
 conditions due to out-of-date state information - and no one 
 reviewing the PR saw how exposing that state information would 
 actually enable anything. So, please provide a use case where 
 exposing that state information actually enables something that 
 you can't do without it.

 - Jonathan M Davis


Hi Jonathan.

have this feature. On of the example is to check the status of 
the tasks - if it was successfully finished, canceled, killed by 
exception.
Some simple example can be found here: 
https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstatus?view=net-7.0
Oct 30 2023
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, October 30, 2023 1:48:46 AM MDT Sergey via Digitalmars-d wrote:

 On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis

 wrote:

 If you have a good use case, then it may make sense to expose
 the state information, but as was pointed out in your previous
 PR, exposing that state information is likely to mislead
 programmers and risk causing them to write code that has race
 conditions due to out-of-date state information - and no one
 reviewing the PR saw how exposing that state information would
 actually enable anything. So, please provide a use case where
 exposing that state information actually enables something that
 you can't do without it.

 - Jonathan M Davis


 Hi Jonathan.

 have this feature. On of the example is to check the status of
 the tasks - if it was successfully finished, canceled, killed by
 exception.
 Some simple example can be found here:
 https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstat
 us?view=net-7.0


Thanks for the info.

Task in std.parallelism already provides the done property to ask whether a
task has been completed (be it successfully or by an exception being
thrown). It does not provide any way to cancel tasks, and the functions on
Task which deal with actually making it do anything are largely variations
on getting the result (be it by getting it because it's already ready, by
waiting for it to be completed, or by actually forcing the task to be done
on the current thread to get the result). As such, there does not appear to
be anything useful which can be done based on the task status except based
on whether it's done or not - which Task already provides.

So, with the API that std.parallelism provides, actually making the
TaskStatus public does not appear to have any useful purpose, and by its
very nature, the answer stands a decent chance of being out-of-date, because
once the TaskStatus is outside of the Task, it's just information on what
the status was when it was synchronized from the thread that it was on, not
information on what the actual, current status is. So, acting on that
information risks introducing race conditions (assuming that you can
actually do anything with that information), and if you can't actually do
anything with that information (and std.parallelism doesn't seem to make it
so that you can), then there's no point in exposing it.


obviously has if it's going to allow things like canceling tasks), but no
one has provided a good reason for why it should be exposed in
std.parallelism beyond the done property which already exists. And sadly,
Imperatorn has repeatedly decided to get mad with us rather than engage in a
technical discussion on why exposing the task's status beyond having the
done property would actually be a good idea. It's quite possible that there
is something that we are missing, and exposing the TaskStatus actually makes
sense, but there need to be technical reasons for that, and none have been
presented.

- Jonathan M Davis
Oct 30 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis 
wrote:

 On Monday, October 30, 2023 1:48:46 AM MDT Sergey via 
 Digitalmars-d wrote:

 On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis

 wrote:

 If you have a good use case, then it may make sense to 
 expose the state information, but as was pointed out in your 
 previous PR, exposing that state information is likely to 
 mislead programmers and risk causing them to write code that 
 has race conditions due to out-of-date state information - 
 and no one reviewing the PR saw how exposing that state 
 information would actually enable anything. So, please 
 provide a use case where exposing that state information 
 actually enables something that you can't do without it.

 - Jonathan M Davis


 Hi Jonathan.

 have this feature. On of the example is to check the status of
 the tasks - if it was successfully finished, canceled, killed 
 by
 exception.
 Some simple example can be found here:
 https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstat
 us?view=net-7.0


 Thanks for the info.

 Task in std.parallelism already provides the done property to 
 ask whether a task has been completed (be it successfully or by 
 an exception being thrown). It does not provide any way to 
 cancel tasks, and the functions on Task which deal with 
 actually making it do anything are largely variations on 
 getting the result (be it by getting it because it's already 
 ready, by waiting for it to be completed, or by actually 
 forcing the task to be done on the current thread to get the 
 result). As such, there does not appear to be anything useful 
 which can be done based on the task status except based on 
 whether it's done or not - which Task already provides.

 So, with the API that std.parallelism provides, actually making 
 the TaskStatus public does not appear to have any useful 
 purpose, and by its very nature, the answer stands a decent 
 chance of being out-of-date, because once the TaskStatus is 
 outside of the Task, it's just information on what the status 
 was when it was synchronized from the thread that it was on, 
 not information on what the actual, current status is. So, 
 acting on that information risks introducing race conditions 
 (assuming that you can actually do anything with that 
 information), and if you can't actually do anything with that 
 information (and std.parallelism doesn't seem to make it so 
 that you can), then there's no point in exposing it.

 It might make sense to expose the TaskStatus with a different 

 canceling tasks), but no one has provided a good reason for why 
 it should be exposed in std.parallelism beyond the done 
 property which already exists. And sadly, Imperatorn has 
 repeatedly decided to get mad with us rather than engage in a 
 technical discussion on why exposing the task's status beyond 
 having the done property would actually be a good idea. It's 
 quite possible that there is something that we are missing, and 
 exposing the TaskStatus actually makes sense, but there need to 
 be technical reasons for that, and none have been presented.

 - Jonathan M Davis


I just have very limited time to explain everything, but I can 
start.

Given the provided link
https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstatus?view=net-7.0

As you can see it contains TaskStatus.

| Canceled                     | 6 | The task acknowledged 
cancellation by throwing an OperationCanceledException with its 
own CancellationToken while the token was in signaled state, or 
the task's CancellationToken was already signaled before the task 
started executing. For more information, see Task Cancellation. | 
   |   |
|------------------------------|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-:|:-:|
| Created                      | 0 | The task has been 
initialized but has not yet been scheduled.                       
                                                                   
                                                                   
                                                                 | 
   |   |
| Faulted                      | 7 | The task completed due to an 
unhandled exception.                                              
                                                                   
                                                                   
                                                      |   |   |
| RanToCompletion              | 5 | The task completed execution 
successfully.                                                     
                                                                   
                                                                   
                                                      |   |   |
| Running                      | 3 | The task is running but has 
not yet completed.                                                
                                                                   
                                                                   
                                                       |   |   |
| WaitingForActivation         | 1 | The task is waiting to be 
activated and scheduled internally by the .NET infrastructure.    
                                                                   
                                                                   
                                                         |   |   |
| WaitingForChildrenToComplete | 4 | The task has finished 
executing and is implicitly waiting for attached child tasks to 
complete.                                                         
                                                                   
                                                               |   
|   |
| WaitingToRun                 | 2 | The task has been scheduled 
for execution but has not yet begun executing.

If we divide it in time, short term, middle term and long term 
changes.

A first change could for example be to expose the status as is, 
but as discussed earlier, it was not meant to be exposed from the 
beginning, but via alias this, it was just a mistake. I can 
understand that, and removing it makes sense.

A middle term change could be to implement a way to get a real 
status from a task in a correct way, whatever that would mean in 
D. The implemenation is not important.

A long term change would be a complete rewrite where basically a 
very detailed status could be probed from the task.

Imagine you have a super loop concept where you check the 
individual tasks. Now, what does checking a task mean?

In terms of what D could provide it would mean is it started, is 
it running or is it completed/done/failed/unknown. Much less than 


If you can only check if it's done, you don't know if it hasn't 
started yet or if it's running. The negation of "done" does not 
mean that it's running, it could also not be started.

I'm not talking about the current implementation in D. I am 
talking about a solution where you have a Task and you want to 
get the status from that task.

You will need to have to imagine a future object that can do this.

Of course I could try and rewrite Task, but it would probably 
take several weeks because I have barely looked at the code for 
it.
Oct 30 2023
next sibling parent reply duckchess <duckchess chess.com> writes:
On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis 
 wrote:

 [...]


 I just have very limited time to explain everything, but I can 
 start.

 [...]


the second you query the status and get 'WaitingToRun' back, that 
same information is potentially outdated and the task might have 
started before you do anything with this information. so you 
cannot rely on it anyway. so what do you need this information 
for?
Oct 30 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 19:37:35 UTC, duckchess wrote:

 On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis 
 wrote:

 [...]


 I just have very limited time to explain everything, but I can 
 start.

 [...]


 the second you query the status and get 'WaitingToRun' back, 
 that same information is potentially outdated and the task 
 might have started before you do anything with this 
 information. so you cannot rely on it anyway. so what do you 
 need this information for?


antihelp++;
Oct 30 2023
next sibling parent reply Olaf <geschmackvollintensiverfalke 10minutenmail.xyz> writes:
On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:

 antihelp++;


What a nice guy.
Oct 30 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 19:52:57 UTC, Olaf wrote:

 On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:

 antihelp++;


 What a nice guy.


:)
Oct 30 2023
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 19:37:35 UTC, duckchess wrote:

 On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis 
 wrote:

 [...]


 I just have very limited time to explain everything, but I 
 can start.

 [...]


 the second you query the status and get 'WaitingToRun' back, 
 that same information is potentially outdated and the task 
 might have started before you do anything with this 
 information. so you cannot rely on it anyway. so what do you 
 need this information for?


 antihelp++;


https://xyproblem.info/
Oct 31 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 31 October 2023 at 15:17:45 UTC, Meta wrote:

 On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 19:37:35 UTC, duckchess wrote:

 On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis 
 wrote:

 [...]


 I just have very limited time to explain everything, but I 
 can start.

 [...]


 the second you query the status and get 'WaitingToRun' back, 
 that same information is potentially outdated and the task 
 might have started before you do anything with this 
 information. so you cannot rely on it anyway. so what do you 
 need this information for?


 antihelp++;


 https://xyproblem.info/


Yes
Oct 31 2023
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis 
 wrote:

[...]




 I just have very limited time to explain everything, but I can 
 start.

 [...]


https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-7.0
Oct 30 2023
prev sibling parent crimm <candaceadams bluetrain.io> writes:
Good
Nov 04 2023
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 Can we count on that if we find an issue with D that it will be 
 taken care of? And if so, how, and by whom? That it will not be 
 silently ignored for years? How can we safeguard against that?


By trying to be a net-positive contributor to the D ecosystem and 
especially core team: libraries, but also mentoring, money, etc. 
You create the incentives to help your company.
D is a communal effort, without supporting the community and 
"giving back" D wouldn't exist. It's really quite hard to do well.
Oct 30 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 14:19:58 UTC, Guillaume Piolat 
wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 Can we count on that if we find an issue with D that it will 
 be taken care of? And if so, how, and by whom? That it will 
 not be silently ignored for years? How can we safeguard 
 against that?


 By trying to be a net-positive contributor to the D ecosystem 
 and especially core team: libraries, but also mentoring, money, 
 etc. You create the incentives to help your company.
 D is a communal effort, without supporting the community and 
 "giving back" D wouldn't exist. It's really quite hard to do 
 well.


Well. I took a quick look at phobos for example.

And it's been almost unchanged since 2019.

We discussed this on Discord trying to understand why.

Some name Andrei "leaving" is a reason, Wilzbach was also a 
contributor who left. And Jack Stouffer.

Some mentioned that betterC got too much attention and someone 
else said too heavy focus on nogc slowed things down in general.

I don't know which of these are correct, but it's a bit worrying.

Do you have an explaination to why the number of contributions to 
phobos has decreased so much since about 2018-2019?
Oct 30 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 30 October 2023 at 14:30:25 UTC, Imperatorn wrote:

 [snip]
 Well. I took a quick look at phobos for example.

 And it's been almost unchanged since 2019.

 We discussed this on Discord trying to understand why.

 Some name Andrei "leaving" is a reason, Wilzbach was also a 
 contributor who left. And Jack Stouffer.

 Some mentioned that betterC got too much attention and someone 
 else said too heavy focus on nogc slowed things down in general.

 I don't know which of these are correct, but it's a bit 
 worrying.

 Do you have an explaination to why the number of contributions 
 to phobos has decreased so much since about 2018-2019?


I'm not sure how you're measuring "contributions", but I think 
there's a combination of phobos being more mature so less work 
needs to be done on it and code.dlang.org gaining more prominence 
in the community. If people have some new functionality they want 
to add, there is a much higher bar to get it added to phobos than 
to post a new library on code.dlang.org. That being said, there 
have been a few new modules in packages since 2018-9, such as 
std.sumtype (which itself began as a dub package).

A few years ago, Andrei had begun some effort to think about a 
phobos v2, but I haven't heard much about it since then.
Oct 30 2023
prev sibling next sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Monday, 30 October 2023 at 14:30:25 UTC, Imperatorn wrote:

 Do you have an explaination to why the number of contributions 
 to phobos has decreased so much since about 2018-2019?


A combination of:
- std.experimental.allocator and std.experimental.logger faced 
increasing scrutiny, it took a long-time and ended up underused 
anyway.
- Phobos being well used and mature, with very-high quality stuff 
that is hard to produce.
- disinterest for Phobos additions (driven by "no way to remove 
stuff") versus the reactivity in DUB, where API can evolve more 
easily
- also being somewhat not possible to use in all cases (-betterC, 
alt. runtimes)

Personally I think the STL Stepanov-style is a dead end and we 
were oversold composable algorithms, that fail to create 
understandability.
Oct 30 2023
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Monday, 30 October 2023 at 14:30:25 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 14:19:58 UTC, Guillaume Piolat 
 wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 Can we count on that if we find an issue with D that it will 
 be taken care of? And if so, how, and by whom? That it will 
 not be silently ignored for years? How can we safeguard 
 against that?


 By trying to be a net-positive contributor to the D ecosystem 
 and especially core team: libraries, but also mentoring, 
 money, etc. You create the incentives to help your company.
 D is a communal effort, without supporting the community and 
 "giving back" D wouldn't exist. It's really quite hard to do 
 well.


 Well. I took a quick look at phobos for example.

 And it's been almost unchanged since 2019.

 We discussed this on Discord trying to understand why.

 Some name Andrei "leaving" is a reason, Wilzbach was also a 
 contributor who left. And Jack Stouffer.

 Some mentioned that betterC got too much attention and someone 
 else said too heavy focus on nogc slowed things down in general.

 I don't know which of these are correct, but it's a bit 
 worrying.

 Do you have an explaination to why the number of contributions 
 to phobos has decreased so much since about 2018-2019?


There's plenty of work to be done in Phobos, the issue is finding 
contributors. We need replacements for std.{json,xml}. I wouldn't 
mind replacing/updating std.socket either. Robert Schadek's made 
the case more than once that we need more file formats in there 
too,  which I agree with. Then there's the fact that we're 
currently concentrating on finishing/stabilising instead of 
adding new features.

The prerequisite right now in my opinion is finishing allocators 
and moving them out of experimental. I don't think it makes sense 
to start work on Phobos v2 before v1 is done, and it isn't. It 
doesn't help that I need to figure out how to include the 
library's evolution in the proposal for editions.
Oct 31 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 31/10/2023 9:28 PM, Atila Neves wrote:

 There's plenty of work to be done in Phobos, the issue is finding 
 contributors. We need replacements for std.{json,xml}. I wouldn't mind 
 replacing/updating std.socket either. Robert Schadek's made the case 
 more than once that we need more file formats in there too, which I 
 agree with. Then there's the fact that we're currently concentrating on 
 finishing/stabilising instead of adding new features.
 
 The prerequisite right now in my opinion is finishing allocators and 
 moving them out of experimental. I don't think it makes sense to start 
 work on Phobos v2 before v1 is done, and it isn't. It doesn't help that 
 I need to figure out how to include the library's evolution in the 
 proposal for editions.


Two years ago you said you would talk to me about what needed to be done 
with std.experimental.allocators, you have not.

I was motivated at the time to see them completed. I no longer am.

Paul Backus has currently taken up the task with some feedback from 
myself and is doing R&D on what an allocator API should look like (as 
the current one has some mighty big problems with it).

The problem has not been finding contributors, its aligning the window 
of time when a contributor is willing and motivated to do something and 
when leadership is receptive of it.

I am reminded about std.uni's table generator. You said one thing on one 
previous PR, and on mine after I had done the work wouldn't say anything 
affirmative about it going in. What is absolutely sad about this is 
after it was in I heard that Symmetry were starting to get uneasy about 
the tables being so old and were thinking about replacing the entire thing.

There is much to learn from before going forward positively and for a 
lot of previous contributors that has been: "Not worth it, they are not 
receptive or encouraging of my contributions".
Oct 31 2023
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 31/10/2023 9:28 PM, Atila Neves wrote:

 There's plenty of work to be done in Phobos, the issue is 
 finding contributors. We need replacements for std.{json,xml}. 
 I wouldn't mind replacing/updating std.socket either. Robert 
 Schadek's made the case more than once that we need more file 
 formats in there too, which I agree with. Then there's the 
 fact that we're currently concentrating on 
 finishing/stabilising instead of adding new features.
 
 The prerequisite right now in my opinion is finishing 
 allocators and moving them out of experimental. I don't think 
 it makes sense to start work on Phobos v2 before v1 is done, 
 and it isn't. It doesn't help that I need to figure out how to 
 include the library's evolution in the proposal for editions.


 Two years ago you said you would talk to me about what needed 
 to be done with std.experimental.allocators, you have not.

 I was motivated at the time to see them completed. I no longer 
 am.


Sorry about that, I clearly dropped the ball. Want to restart?


 Paul Backus has currently taken up the task with some feedback 
 from myself and is doing R&D on what an allocator API should 
 look like (as the current one has some mighty big problems with 
 it).


I also did some R&D recently, and as soon as I'm done with 
editions I want to talk to him about exactly this. And Timon, 
probably.


 I am reminded about std.uni's table generator. You said one 
 thing on one previous PR, and on mine after I had done the work 
 wouldn't say anything affirmative about it going in. What is 
 absolutely sad about this is after it was in I heard that 
 Symmetry were starting to get uneasy about the tables being so 
 old and were thinking about replacing the entire thing.


I don't know enough about the issue to opine, unfortunately.


 There is much to learn from before going forward positively and 
 for a lot of previous contributors that has been: "Not worth 
 it, they are not receptive or encouraging of my contributions".


Valid. The best case scenario is aligning contributors' interests 
and time with what's good for the language/library/ecosystem/etc.
Oct 31 2023
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 31 October 2023 at 10:50:20 UTC, Atila Neves wrote:

 On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 Paul Backus has currently taken up the task with some feedback 
 from myself and is doing R&D on what an allocator API should 
 look like (as the current one has some mighty big problems 
 with it).


 I also did some R&D recently, and as soon as I'm done with 
 editions I want to talk to him about exactly this. And Timon, 
 probably.


I've published a first-draft writeup of my overall approach as a 
gist [1], and hope to have a working demo/proof-of-concept up on 
github sometime in the next few days. I look forward to comparing 
our findings. :)

[1] 
https://gist.github.com/pbackus/29c520bc4e1f4aa075c9171db791d234
Oct 31 2023
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 31 October 2023 at 10:50:20 UTC, Atila Neves wrote:

 On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 [...]


 Sorry about that, I clearly dropped the ball. Want to restart?


 [...]


 I also did some R&D recently, and as soon as I'm done with 
 editions I want to talk to him about exactly this. And Timon, 
 probably.


 [...]


 I don't know enough about the issue to opine, unfortunately.


 [...]


 Valid. The best case scenario is aligning contributors' 
 interests and time with what's good for the 
 language/library/ecosystem/etc.


What are your comments on this?

https://forum.dlang.org/post/jcgphabrvyjecnjzjlpf forum.dlang.org
Oct 31 2023
prev sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 31/10/2023 11:50 PM, Atila Neves wrote:

 On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 I was motivated at the time to see them completed. I no longer am.


 
 Sorry about that, I clearly dropped the ball. Want to restart?


Not particularly. I'll leave it to Paul to communicate the big stuff.

Mine: 
https://github.com/Project-Sidero/basic_memory/tree/main/source/sidero/base/allocators

Only things I'd change is dump TypeInfo in favor of my own thing, and 
allow getting rid of duplicative state (defensive programming).


 I am reminded about std.uni's table generator. You said one thing on 
 one previous PR, and on mine after I had done the work wouldn't say 
 anything affirmative about it going in. What is absolutely sad about 
 this is after it was in I heard that Symmetry were starting to get 
 uneasy about the tables being so old and were thinking about replacing 
 the entire thing.


 
 I don't know enough about the issue to opine, unfortunately.


See that is concerning. That means you haven't done risk analysis yet. 
After all, having tables that were later manually modified (which they 
were) without the table generator is a ticking time bomb. That could 
stop dmd being released.
Oct 31 2023
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 31 October 2023 at 16:17:54 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 31/10/2023 11:50 PM, Atila Neves wrote:

 I am reminded about std.uni's table generator. You said one 
 thing on one previous PR, and on mine after I had done the 
 work wouldn't say anything affirmative about it going in. 
 What is absolutely sad about this is after it was in I heard 
 that Symmetry were starting to get uneasy about the tables 
 being so old and were thinking about replacing the entire 
 thing.


 
 I don't know enough about the issue to opine, unfortunately.


 See that is concerning. That means you haven't done risk 
 analysis yet. After all, having tables that were later manually 
 modified (which they were) without the table generator is a 
 ticking time bomb. That could stop dmd being released.


It seems to me like this is a symptom of D's leaders being spread 
too thin. Is it really reasonable to expect Atila to be 
up-to-speed on every last detail when he has so many different 
projects to oversee?

Atila shouldn't have to do risk analysis on a project like this. 
He should be able to delegate that task to someone (like 
yourself) who has the motivation to take it on and whom he can 
trust do a good job. And that person should then be responsible 
for presenting the results in a way that Atila can digest without 
needing to ramp himself up on all of the relevant background 
knowledge.

I know we have people in the D community who are capable of 
filling this role. So, why aren't they? What do we need to do to 
make that happen?
Oct 31 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
I think that you may have misunderstood the problem here.

Atila took over a production code base. He appears to not have done any 
risk analysis to understand how it could fail as a whole nor was there 
anything to tell him what was a risk.

When alerted to a problem agreed, when it was time to pull a PR, didn't 
engage in it to ensure a serious risk that could prevent a release of 
dmd was resolved.

The community (me & Dmitry), staff (Razvan) did our jobs to ensure it 
was resolved even with it being held up due to leadership 
"unwillingness" to ensure it was resolved.

There is something to learn from in all of this to ensure that we are 
not put in this situation again. Which is why I bring it up, to ensure 
that we don't have a repeat :)
Oct 31 2023
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 31 October 2023 at 18:04:58 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 When alerted to a problem agreed, when it was time to pull a 
 PR, didn't engage in it to ensure a serious risk that could 
 prevent a release of dmd was resolved.

 The community (me & Dmitry), staff (Razvan) did our jobs to 
 ensure it was resolved even with it being held up due to 
 leadership "unwillingness" to ensure it was resolved.


Thanks for explaining. If leadership is failing to prioritize 
release-blocking issues over other tasks, even when their urgency 
is clearly communicated, that is certainly cause for concern.
Oct 31 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 01/11/2023 7:23 AM, Paul Backus wrote:

 Thanks for explaining. If leadership is failing to prioritize 
 release-blocking issues over other tasks, even when their urgency is 
 clearly communicated, that is certainly cause for concern.


In this particular case for std.uni, it was the potential for there to 
be one at some unknown point in the future. It was just a giant time 
bomb waiting to go off.

And you know what? If that table generator had been deleted completely, 
it could have taken us months to reproduce from scratch. Imagine how 
people would react if we couldn't release dmd for that length of time, 
due to something so "unimportant" to a lot of people.
Oct 31 2023
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 31 October 2023 at 16:17:54 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 31/10/2023 11:50 PM, Atila Neves wrote:

 [...]


 Not particularly. I'll leave it to Paul to communicate the big 
 stuff.

 Mine: 
 https://github.com/Project-Sidero/basic_memory/tree/main/source/sidero/base/allocators

 Only things I'd change is dump TypeInfo in favor of my own 
 thing, and allow getting rid of duplicative state (defensive 
 programming).


 [...]


 See that is concerning. That means you haven't done risk 
 analysis yet. After all, having tables that were later manually 
 modified (which they were) without the table generator is a 
 ticking time bomb. That could stop dmd being released.


Then I need more information from people who *do* know about the 
issue.
Nov 02 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 02/11/2023 10:54 PM, Atila Neves wrote:

 Then I need more information from people who /do/ know about the issue.


Okay, then we need to make a change to the PR managers roles.

If they tell you that you need to review something, you actually have to 
review it and not just comment "I don't know".

They are your backup plan. They determine if you need to be involved. 
They have already determined that the information is there to require 
you to put in the effort.

This alone should prevent a repeat.
Nov 02 2023
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 31 October 2023 at 08:28:26 UTC, Atila Neves wrote:

 On Monday, 30 October 2023 at 14:30:25 UTC, Imperatorn wrote:

 On Monday, 30 October 2023 at 14:19:58 UTC, Guillaume Piolat





 There's plenty of work to be done in Phobos, the issue is 
 finding contributors. We need replacements for std.{json,xml}. 
 I wouldn't mind replacing/updating std.socket either. Robert 
 Schadek's made the case more than once that we need more file 
 formats in there too,  which I agree with. Then there's the 
 fact that we're currently concentrating on 
 finishing/stabilising instead of adding new features.


Agreed. Stability > Features, almost always.

I can try to contribute to phobos, but the prerequisites for that 
happening is there must be an open discussion, something like a 
"probability index" that something will get merged. At our 
company we are already working far over 100% capacity, we can't 
afford putting a lot of time into something that will just get 
rejected after months of work. Also, since D unfortunately is 
still quite small, we don't really have a choice when it comes to 
looking at what other languages do.

If we want to stay competitive we must at least take a peek at 

personally despise Rust, we must still look. Use the good ideas, 

good ideas in there imo, and I am far from alone in thinking that.

Of course what constitues a good or bad idea is subjective, but I 
am thinking something like if it seems something is widely 
regarded as good in multiple communities, the probability that it 
is good is high, and it might be worth investigating.
Oct 31 2023
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 31 October 2023 at 09:38:29 UTC, Imperatorn wrote:

 I personally despise Rust


No matter how critical people are of D's leadership, we can take 
solace in the fact that they will never be as bad as in Rust.

https://youtu.be/QEnuzwCWpgQ?si=6yDWLoOYVpBQNAhk
Oct 31 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 31 October 2023 at 15:08:21 UTC, Meta wrote:

 On Tuesday, 31 October 2023 at 09:38:29 UTC, Imperatorn wrote:

 I personally despise Rust


 No matter how critical people are of D's leadership, we can 
 take solace in the fact that they will never be as bad as in 
 Rust.

 https://youtu.be/QEnuzwCWpgQ?si=6yDWLoOYVpBQNAhk


True 😅
Oct 31 2023
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 31 October 2023 at 08:28:26 UTC, Atila Neves wrote:

 *snip*


Do you have anything written up with specifics for what you have 
in mind for all these things?
Oct 31 2023
parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 1 November 2023 at 02:00:11 UTC, Adam D Ruppe wrote:

 On Tuesday, 31 October 2023 at 08:28:26 UTC, Atila Neves wrote:

 *snip*


 Do you have anything written up with specifics for what you 
 have in mind for all these things?


Not yet, no. I guess I should fix that.
Nov 02 2023
prev sibling next sibling parent reply A moo person <moo_mail fake.com> writes:
I would say it's a mistake to rely on D in the current state of 
things. The honest reality is the language has stagnated. I been 
lurking in these forms for like 10 years now, use to post a lot 
under a different name, I honestly regret writing so much 
personal code in D because I can't reasonably see a future for it 
with how D has gone. There is a perpetual unwillingness for D to 
change in any meaningful way.

I still pray one day someone will fork the language and start 
working on a D3 to break the stagnation that is the current D, 
but its a pipe dream...
Oct 30 2023
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 30 October 2023 at 17:52:19 UTC, A moo person wrote:

 personal code in D because I can't reasonably see a future for 
 it with how D has gone. There is a perpetual unwillingness for 
 D to change in any meaningful way.

 I still pray one day someone will fork the language and start 
 working on a D3 to break the stagnation that is the current D, 
 but its a pipe dream...


In which languages could you see future?
Oct 30 2023
parent reply A moo person <moo_mail fake.com> writes:
On Monday, 30 October 2023 at 18:28:02 UTC, Sergey wrote:

 On Monday, 30 October 2023 at 17:52:19 UTC, A moo person wrote:

 personal code in D because I can't reasonably see a future for 
 it with how D has gone. There is a perpetual unwillingness for 
 D to change in any meaningful way.

 I still pray one day someone will fork the language and start 
 working on a D3 to break the stagnation that is the current D, 
 but its a pipe dream...


 In which languages could you see future?


A big problem is I have never once seen a job posting asking for 
D programmers. Tons of jobs still asking for c and cpp, tons of 

programmers now, but I have honestly never once seen a job 
posting asking for D programmers and that is with me actually 
going out of my way to search for them.

Nothing lasts forever, I assume eventually all languages will 
die, but D feels likes the walking dead at this point. All 
momentum feels like it was drained out over many many years of 
mismanagement. I can't in good conscious recommend it to people 
anymore even though I love aspects of the language itself so much.

I had a bit of hope when a while back there was that feedback 
request campaign, but after I saw the response to it I pretty 
much lost all hope. I know people here will disagree, I really 
resisted coming to this conclusion myself because I have sunk a 
lot of personal time and energy into writing D code. But that's 
where I am now after 10 years of hobby D programming.
Oct 30 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 30 October 2023 at 19:01:09 UTC, A moo person wrote:

 A big problem is I have never once seen a job posting asking 
 for D programmers. Tons of jobs still asking for c and cpp, 

 programmers now, but I have honestly never once seen a job 
 posting asking for D programmers and that is with me actually 
 going out of my way to search for them.


It is well known fact. But it doesn't mean a lot actually.
And I know cases when actually D developers were searched with 



 Nothing lasts forever, I assume eventually all languages will 
 die, but D feels likes the walking dead at this point. All 
 momentum feels like it was drained out over many many years of 
 mismanagement. I can't in good conscious recommend it to people 
 anymore even though I love aspects of the language itself so 
 much.


Recommend people for what? It depends. I think it is quite safe 
to recommend D for personal project, to have joy and fun. Also if 
they need to prepare some MVP fast and if all components are 
available in std/3rd party libraries (check the quality of those 
libraries not too hard). For something else - it could be harder. 
I just mean it is not 0/1 question..


 I had a bit of hope when a while back there was that feedback 
 request campaign, but after I saw the response to it I pretty 
 much lost all hope. I know people here will disagree, I really 
 resisted coming to this conclusion myself because I have sunk a 
 lot of personal time and energy into writing D code. But that's 
 where I am now after 10 years of hobby D programming.


I thought stabilization the lang and fixing bugs were a 
long-waited wish of many users.
But there will be always 2 sides of the community: who already 
fine and don't want to break a lot, and who is not yet fine and 
want to break a lot to be fine as well :)
Oct 30 2023
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 30 October 2023 at 20:47:34 UTC, Sergey wrote:

 On Monday, 30 October 2023 at 19:01:09 UTC, A moo person wrote:

 A big problem is I have never once seen a job posting asking 
 for D programmers. Tons of jobs still asking for c and cpp, 

 rust programmers now, but I have honestly never once seen a 
 job posting asking for D programmers and that is with me 
 actually going out of my way to search for them.


 It is well known fact. But it doesn't mean a lot actually.
 And I know cases when actually D developers were searched with 



Can we stop that btw; like post both a c++ and a d job if youll 
take either but like can I just have job alerts
Oct 30 2023
parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 31 October 2023 at 01:05:30 UTC, monkyyy wrote:

 On Monday, 30 October 2023 at 20:47:34 UTC, Sergey wrote:

 On Monday, 30 October 2023 at 19:01:09 UTC, A moo person wrote:

 A big problem is I have never once seen a job posting asking 
 for D programmers. Tons of jobs still asking for c and cpp, 

 rust programmers now, but I have honestly never once seen a 
 job posting asking for D programmers and that is with me 
 actually going out of my way to search for them.


 It is well known fact. But it doesn't mean a lot actually.
 And I know cases when actually D developers were searched with 



 Can we stop that btw; like post both a c++ and a d job if youll 
 take either but like can I just have job alerts


It is very popular practice right now. Even if we are not 
speaking about D..
Many positions just have something like that: "Proven experience 
in software development, including proficiency in programming 
languages such as Java, Python, C++, or others".
Oct 31 2023
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 30 October 2023 at 17:52:19 UTC, A moo person wrote:

 I would say it's a mistake to rely on D in the current state of 
 things. The honest reality is the language has stagnated. I 
 been lurking in these forms for like 10 years now, use to post 
 a lot under a different name, I honestly regret writing so much 
 personal code in D because I can't reasonably see a future for 
 it with how D has gone. There is a perpetual unwillingness for 
 D to change in any meaningful way.

 I still pray one day someone will fork the language and start 
 working on a D3 to break the stagnation that is the current D, 
 but its a pipe dream...


I hear you, I am just a bit more optimistic. I think if we just 
can agree on some things, D can still thrive. But at the same 
point I hear you, phobos for example hasn't changed much since 
2019 when Andrei, Wilzbach and Jack Stouffer stopped contributing.
Oct 30 2023
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 We are merging companies and our new product will be integrated 
 in all our devices.


It's only been 4 days, and I've got varied responses. Both praise 
and criticism, which was expected.

I currently don't see any red flags or showstoppers for us using 
D in this project.

Is it complete? No.
Is it perfect? Also no.

But, it's good enough that we think it's better than C/C++, which 
would be the alternative. Everything can be compared on various 
dimensions of course. But our summary of the cold hard facts 
still shows that D is better.

Windows x64 and Linux arm64 are our main targets, and we haven't 
had any problems building for those (both on host and 
cross-compiling).

We will do this project in D, and we hope that things will 
continue as smoothly as it has so far.

We just want to say thanks to all contributors, big or small. 
There is no D without the community. A language is a living 
entity.
Nov 02 2023
next sibling parent reply Emmanuel Danso Nyarko <emmankoko519 gmail.com> writes:
On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 [...]


 It's only been 4 days, and I've got varied responses. Both 
 praise and criticism, which was expected.

 [...]


What will be the project be about ?
Nov 02 2023
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 2 November 2023 at 23:44:14 UTC, Emmanuel Danso 
Nyarko wrote:

 On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 [...]


 It's only been 4 days, and I've got varied responses. Both 
 praise and criticism, which was expected.

 [...]


 What will be the project be about ?


We will start small. It will be a kind of status monitor and 
redundancy service.
Nov 03 2023
parent Emmanuel Danso Nyarko <emmankoko519 gmail.com> writes:
On Friday, 3 November 2023 at 08:15:40 UTC, Imperatorn wrote:

 On Thursday, 2 November 2023 at 23:44:14 UTC, Emmanuel Danso 
 Nyarko wrote:

 On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:

 On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:

 [...]


 It's only been 4 days, and I've got varied responses. Both 
 praise and criticism, which was expected.

 [...]


 What will be the project be about ?


 We will start small. It will be a kind of status monitor and 
 redundancy service.


That's cool an idea
Nov 03 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:

 I currently don't see any red flags or showstoppers for us 
 using D in this project.

 Is it complete? No.
 Is it perfect? Also no.

 But, it's good enough that we think it's better than C/C++, 
 which would be the alternative. Everything can be compared on 
 various dimensions of course. But our summary of the cold hard 
 facts still shows that D is better.

 Windows x64 and Linux arm64 are our main targets, and we 
 haven't had any problems building for those (both on host and 
 cross-compiling).

 We will do this project in D, and we hope that things will 
 continue as smoothly as it has so far.

 We just want to say thanks to all contributors, big or small. 
 There is no D without the community. A language is a living 
 entity.


Is there an associated GUI with this program?
Nov 03 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 3 November 2023 at 11:44:44 UTC, IGotD- wrote:

 On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:

 I currently don't see any red flags or showstoppers for us 
 using D in this project.

 Is it complete? No.
 Is it perfect? Also no.

 But, it's good enough that we think it's better than C/C++, 
 which would be the alternative. Everything can be compared on 
 various dimensions of course. But our summary of the cold hard 
 facts still shows that D is better.

 Windows x64 and Linux arm64 are our main targets, and we 
 haven't had any problems building for those (both on host and 
 cross-compiling).

 We will do this project in D, and we hope that things will 
 continue as smoothly as it has so far.

 We just want to say thanks to all contributors, big or small. 
 There is no D without the community. A language is a living 
 entity.


 Is there an associated GUI with this program?


There's no direct gui for it. However, it will talk to a backend, 
then the FE guys will create a desktop application which consumes 
the API and presents stuff. So indirectly there is.
Nov 03 2023