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