digitalmars.D - Future of D
- Imperatorn (22/22) Oct 29 2023 We are merging companies and our new product will be integrated
- Paul Backus (5/13) Oct 29 2023 It sounds like you should probably get in touch with the D
- Imperatorn (2/18) Oct 29 2023 Ok, we will contact him and see what can be done. Thanks!
- Imperatorn (2/18) Oct 29 2023 Thanks, I got in contact with him now 👍
- Abdulhaq (15/28) Oct 29 2023 I can't think of any 'serious' programming language where the
- Imperatorn (5/9) Oct 29 2023 Can you explain why you responded to this?
- Abdulhaq (6/15) Oct 29 2023 Because you asked the question and I have a useful answer so I
- Paolo Invernizzi (15/38) Oct 29 2023 I can testify that D is industry-friendly, more than lot of other
- Imperatorn (4/20) Oct 29 2023 That's very good to hear!
- monkyyy (5/8) Oct 29 2023 I'd probably consider hiring compiler devs who are doing
- Imperatorn (4/13) Oct 29 2023 Maybe, but it would be best if we didn't have to and could stay
- monkyyy (9/27) Oct 29 2023 In my experience, only 1 bug report of mine has ever been
- Imperatorn (3/15) Oct 29 2023 Hmm. I will take your points into consideration. Thanks
- IGotD- (7/9) Oct 29 2023 That is the only future of D unfortunately, that someone with a
- Abdulhaq (15/25) Oct 29 2023 Choosing a programming ecosystem for a business is a bit like a
- IGotD- (3/6) Oct 29 2023 Why? I would rather say that forking a programming language in
- Abdulhaq (25/32) Oct 29 2023 Yes that's a fair comment. What I mean is that for most
- monkyyy (6/8) Oct 29 2023 That seems dubious, theres also talk of c++ dying, c++ has super
- Abdulhaq (6/14) Oct 29 2023 Yes reasonable people can certainly differ on this, but the vast
- Imperatorn (2/10) Oct 29 2023 Yes, we don't consider C++ a safe choice.
- bachmeier (14/26) Oct 29 2023 There's a lot of speculation in those two paragraphs. The risk
- Abdulhaq (6/22) Oct 29 2023 Yes it _is_ a lot of speculation, but I think these are the sorts
- Imperatorn (3/13) Oct 29 2023 Can you explain your standpoint? Why do you think so?
- Walter Bright (2/5) Oct 29 2023 What is that change?
- Richard (Rikki) Andrew Cattermole (1/1) Oct 29 2023 I'm pretty certain it was: https://github.com/dlang/phobos/pull/8832
- Imperatorn (10/15) Oct 29 2023 Nevermind, it was just exposing the TaskStatus enum. But it
- Walter Bright (3/7) Oct 29 2023 And a PR:
- Imperatorn (3/10) Oct 29 2023 Yes, it's great to see. Now the next step is to improve it so
- Jonathan M Davis (29/42) Oct 29 2023 You have yet to explain why that information should be made public. Even...
- Imperatorn (4/19) Oct 29 2023 Because it would be wonderful. I could use it to draw a rainbow
- Mike Parker (6/8) Oct 30 2023 Everyone: Let's move any further discussion of string
- Sergey (3/12) Oct 30 2023 Maybe wrong thread, Mike? This one is not about string
- Imperatorn (2/17) Oct 30 2023 I think it was just a wrong post from the other thread
- Mike Parker (2/4) Oct 30 2023 Yes, I took a wrong turn.
- duckchess (3/8) Oct 30 2023 my advice: don't use D in your company. no one will help you any
- Imperatorn (2/11) Oct 30 2023 ?
- Walter Bright (2/2) Oct 30 2023 Sometimes, if we knew what problem you're faced with, we can find the be...
- Imperatorn (21/23) Oct 30 2023 That's good to hear. Since D will be running on at least 50
- Walter Bright (9/33) Oct 31 2023 Thanks for the kind words and contributions! I appreciate them.
- Imperatorn (49/79) Nov 01 2023 I have yet to find a language except D that:
- Olaf (14/18) Nov 01 2023 Wow. That's tough.
- Imperatorn (2/22) Nov 01 2023 Did you reply to the wrong post or in the wrong thread?
- Imperatorn (3/24) Nov 01 2023 What I mean is, why wouldn't Walter appreciate Adams work? I am
- Patrick Schluter (2/7) Oct 30 2023 This attitude won't help you.
- Imperatorn (21/29) Oct 30 2023 Sure, but neither does not trying to understand a basic use case
- Sergey (9/19) Oct 30 2023 Hi Jonathan.
- Jonathan M Davis (32/53) Oct 30 2023 Thanks for the info.
- Imperatorn (74/136) Oct 30 2023 I just have very limited time to explain everything, but I can
- duckchess (6/12) Oct 30 2023 the second you query the status and get 'WaitingToRun' back, that
- Imperatorn (2/16) Oct 30 2023 antihelp++;
- Olaf (2/3) Oct 30 2023 What a nice guy.
- Imperatorn (2/5) Oct 30 2023 :)
- Meta (2/19) Oct 31 2023 https://xyproblem.info/
- Imperatorn (2/22) Oct 31 2023 Yes
- Imperatorn (2/8) Oct 30 2023 https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task...
- crimm (1/1) Nov 04 2023 Good
- Guillaume Piolat (6/9) Oct 30 2023 By trying to be a net-positive contributor to the D ecosystem and
- Imperatorn (12/23) Oct 30 2023 Well. I took a quick look at phobos for example.
- jmh530 (11/23) Oct 30 2023 I'm not sure how you're measuring "contributions", but I think
- Guillaume Piolat (15/17) Oct 30 2023 A combination of:
- Atila Neves (13/38) Oct 31 2023 There's plenty of work to be done in Phobos, the issue is finding
- Richard (Rikki) Andrew Cattermole (18/30) Oct 31 2023 Two years ago you said you would talk to me about what needed to be done...
- Atila Neves (9/40) Oct 31 2023 Sorry about that, I clearly dropped the ball. Want to restart?
- Paul Backus (7/16) Oct 31 2023 I've published a first-draft writeup of my overall approach as a
- Imperatorn (3/17) Oct 31 2023 What are your comments on this?
- Richard (Rikki) Andrew Cattermole (10/23) Oct 31 2023 Not particularly. I'll leave it to Paul to communicate the big stuff.
- Paul Backus (16/30) Oct 31 2023 It seems to me like this is a symptom of D's leaders being spread
- Richard (Rikki) Andrew Cattermole (13/13) Oct 31 2023 I think that you may have misunderstood the problem here.
- Paul Backus (5/11) Oct 31 2023 Thanks for explaining. If leadership is failing to prioritize
- Richard (Rikki) Andrew Cattermole (8/11) Oct 31 2023 In this particular case for std.uni, it was the potential for there to
- Atila Neves (4/18) Nov 02 2023 Then I need more information from people who *do* know about the
- Richard (Rikki) Andrew Cattermole (8/9) Nov 02 2023 Okay, then we need to make a change to the PR managers roles.
- Imperatorn (19/28) Oct 31 2023 Agreed. Stability > Features, almost always.
- Meta (4/5) Oct 31 2023 No matter how critical people are of D's leadership, we can take
- Imperatorn (2/8) Oct 31 2023 True 😅
- Adam D Ruppe (3/4) Oct 31 2023 Do you have anything written up with specifics for what you have
- Atila Neves (2/6) Nov 02 2023 Not yet, no. I guess I should fix that.
- A moo person (10/10) Oct 30 2023 I would say it's a mistake to rely on D in the current state of
- Sergey (2/8) Oct 30 2023 In which languages could you see future?
- A moo person (18/27) Oct 30 2023 A big problem is I have never once seen a job posting asking for
- Imperatorn (5/15) Oct 30 2023 I hear you, I am just a bit more optimistic. I think if we just
- Imperatorn (19/21) Nov 02 2023 It's only been 4 days, and I've got varied responses. Both praise
- Emmanuel Danso Nyarko (2/7) Nov 02 2023 What will be the project be about ?
- Imperatorn (4/13) Nov 03 2023 We will start small. It will be a kind of status monitor and
- Emmanuel Danso Nyarko (2/16) Nov 03 2023 That's cool an idea
- IGotD- (2/18) Nov 03 2023 Is there an associated GUI with this program?
- Imperatorn (4/28) Nov 03 2023 There's no direct gui for it. However, it will talk to a backend,
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
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
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:Ok, we will contact him and see what can be done. Thanks!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
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:Thanks, I got in contact with him now 👍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
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
On Sunday, 29 October 2023 at 16:34:25 UTC, Abdulhaq wrote:On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote: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.We are merging companies and our new product will be integrated in all our devices.
Oct 29 2023
On Sunday, 29 October 2023 at 16:38:22 UTC, Imperatorn wrote:On Sunday, 29 October 2023 at 16:34:25 UTC, Abdulhaq wrote:Because you asked the question and I have a useful answer so I shared it.On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:Can you explain why you responded to this?We are merging companies and our new product will be integrated in all our devices.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
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
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:That's very good to hear! Thanks for your input[...]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
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 usI'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
On Sunday, 29 October 2023 at 16:39:28 UTC, monkyyy wrote:On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote: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.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 usI'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
On Sunday, 29 October 2023 at 16:46:02 UTC, Imperatorn wrote:On Sunday, 29 October 2023 at 16:39:28 UTC, monkyyy 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.On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote: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.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 usI'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 itCan 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
On Sunday, 29 October 2023 at 17:05:10 UTC, monkyyy wrote:On Sunday, 29 October 2023 at 16:46:02 UTC, Imperatorn wrote:Hmm. I will take your points into consideration. Thanks I'm making a list of pros and cons.[...]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.
Oct 29 2023
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 likeThat 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
On Sunday, 29 October 2023 at 17:20:36 UTC, IGotD- wrote:On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote: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.Is the recommended course of action to fork dmd, druntime and phobos and have a completely parallel version of D, a bit likeThat 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
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
On Sunday, 29 October 2023 at 18:00:13 UTC, IGotD- wrote:On Sunday, 29 October 2023 at 17:29:51 UTC, Abdulhaq wrote: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++.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
On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:C++ is the low risk option, for a typical businessThat 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
On Sunday, 29 October 2023 at 18:20:40 UTC, monkyyy wrote:On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote: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.C++ is the low risk option, for a typical businessThat 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
On Sunday, 29 October 2023 at 18:20:40 UTC, monkyyy wrote:On Sunday, 29 October 2023 at 18:12:46 UTC, Abdulhaq wrote:Yes, we don't consider C++ a safe choice.C++ is the low risk option, for a typical businessThat 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
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
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
On Sunday, 29 October 2023 at 17:20:36 UTC, IGotD- wrote:On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:Can you explain your standpoint? Why do you think so? ThanksIs the recommended course of action to fork dmd, druntime and phobos and have a completely parallel version of D, a bit likeThat 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
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
I'm pretty certain it was: https://github.com/dlang/phobos/pull/8832
Oct 29 2023
On Sunday, 29 October 2023 at 18:20:28 UTC, Walter Bright wrote:On 10/29/2023 5:54 AM, Imperatorn wrote: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.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
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/8834Next step is to provide a safe way to get the task status after the pr has been merged.
Oct 29 2023
On Sunday, 29 October 2023 at 20:39:19 UTC, Walter Bright wrote:On 10/29/2023 11:38 AM, Imperatorn wrote:Yes, it's great to see. Now the next step is to improve it so that you can get the task status safely 😎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/8834Next step is to provide a safe way to get the task status after the pr has been merged.
Oct 29 2023
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: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 DavisOn 10/29/2023 11:38 AM, Imperatorn wrote:Yes, it's great to see. Now the next step is to improve it so that you can get the task status safely 😎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/8834Next step is to provide a safe way to get the task status after the pr has been merged.
Oct 29 2023
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:Because it would be wonderful. I could use it to draw a rainbow on the screen.[...]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. [...]
Oct 29 2023
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
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:Maybe wrong thread, Mike? This one is not about string interpolation at allBecause 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
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:I think it was just a wrong post from the other threadOn Sunday, 29 October 2023 at 21:46:51 UTC, Imperatorn wrote:Maybe wrong thread, Mike? This one is not about string interpolation at allBecause 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
On Monday, 30 October 2023 at 12:45:42 UTC, Sergey wrote:Maybe wrong thread, Mike? This one is not about string interpolation at allYes, I took a wrong turn.
Oct 30 2023
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: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.[...]Because it would be wonderful. I could use it to draw a rainbow on the screen.
Oct 30 2023
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: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.[...]Because it would be wonderful. I could use it to draw a rainbow on the screen.
Oct 30 2023
Sometimes, if we knew what problem you're faced with, we can find the best solution. Help us help you!
Oct 30 2023
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
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 futureThanks 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
On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright wrote:On 10/30/2023 11:56 AM, Imperatorn wrote: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.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 futureThanks for the kind words and contributions! I appreciate them.
Nov 01 2023
On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright wrote:On 10/30/2023 11:56 AM, Imperatorn 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[snip]Thanks for the kind words and contributions! I appreciate them. [snip]
Nov 01 2023
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:Did you reply to the wrong post or in the wrong thread?On 10/30/2023 11:56 AM, Imperatorn 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[snip]Thanks for the kind words and contributions! I appreciate them. [snip]
Nov 01 2023
On Wednesday, 1 November 2023 at 11:23:11 UTC, Imperatorn wrote:On Wednesday, 1 November 2023 at 09:00:38 UTC, Olaf wrote:What I mean is, why wouldn't Walter appreciate Adams work? I am of the impression he does.On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright wrote:Did you reply to the wrong post or in the wrong thread?[...]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
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:This attitude won't help you.[...]Because it would be wonderful. I could use it to draw a rainbow on the screen.
Oct 30 2023
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: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.On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis wrote:This attitude won't help you.[...]Because it would be wonderful. I could use it to draw a rainbow on the screen.
Oct 30 2023
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 DavisHi 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
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: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 DavisIf 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 DavisHi 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
Oct 30 2023
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: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.On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis wrote: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 DavisIf 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 DavisHi 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
Oct 30 2023
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: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?[...]I just have very limited time to explain everything, but I can start. [...]
Oct 30 2023
On Monday, 30 October 2023 at 19:37:35 UTC, duckchess wrote:On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:antihelp++;On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis wrote: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?[...]I just have very limited time to explain everything, but I can start. [...]
Oct 30 2023
On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:antihelp++;What a nice guy.
Oct 30 2023
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
On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:On Monday, 30 October 2023 at 19:37:35 UTC, duckchess wrote:https://xyproblem.info/On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:antihelp++;On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis wrote: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?[...]I just have very limited time to explain everything, but I can start. [...]
Oct 31 2023
On Tuesday, 31 October 2023 at 15:17:45 UTC, Meta wrote:On Monday, 30 October 2023 at 19:45:13 UTC, Imperatorn wrote:YesOn Monday, 30 October 2023 at 19:37:35 UTC, duckchess wrote:https://xyproblem.info/On Monday, 30 October 2023 at 19:23:58 UTC, Imperatorn wrote:antihelp++;On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis wrote: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?[...]I just have very limited time to explain everything, but I can start. [...]
Oct 31 2023
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:https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-7.0I just have very limited time to explain everything, but I can start. [...][...]
Oct 30 2023
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
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: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?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
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
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
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: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.On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote: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?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 31 2023
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
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:Sorry about that, I clearly dropped the ball. Want to restart?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).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
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: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/29c520bc4e1f4aa075c9171db791d234Paul 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.
Oct 31 2023
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:What are your comments on this? https://forum.dlang.org/post/jcgphabrvyjecnjzjlpf forum.dlang.org[...]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.
Oct 31 2023
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: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 was motivated at the time to see them completed. I no longer am.Sorry about that, I clearly dropped the ball. Want to restart?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.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.
Oct 31 2023
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: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?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.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.
Oct 31 2023
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
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
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
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:Then I need more information from people who *do* know about the issue.[...]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.
Nov 02 2023
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
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 PiolatThere'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
On Tuesday, 31 October 2023 at 09:38:29 UTC, Imperatorn wrote:I personally despise RustNo 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
On Tuesday, 31 October 2023 at 15:08:21 UTC, Meta wrote:On Tuesday, 31 October 2023 at 09:38:29 UTC, Imperatorn wrote:True 😅I personally despise RustNo 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
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
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:Not yet, no. I guess I should fix that.*snip*Do you have anything written up with specifics for what you have in mind for all these things?
Nov 02 2023
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
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
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: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.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
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 withNothing 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
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: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 alertsA 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
Oct 30 2023
On Tuesday, 31 October 2023 at 01:05:30 UTC, monkyyy wrote:On Monday, 30 October 2023 at 20:47:34 UTC, Sergey wrote: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".On Monday, 30 October 2023 at 19:01:09 UTC, A moo person wrote: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 alertsA 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
Oct 31 2023
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
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
On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:What will be the project be about ?[...]It's only been 4 days, and I've got varied responses. Both praise and criticism, which was expected. [...]
Nov 02 2023
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:We will start small. It will be a kind of status monitor and redundancy service.On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:What will be the project be about ?[...]It's only been 4 days, and I've got varied responses. Both praise and criticism, which was expected. [...]
Nov 03 2023
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:That's cool an ideaOn Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote:We will start small. It will be a kind of status monitor and redundancy service.On Sunday, 29 October 2023 at 12:54:33 UTC, Imperatorn wrote:What will be the project be about ?[...]It's only been 4 days, and I've got varied responses. Both praise and criticism, which was expected. [...]
Nov 03 2023
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
On Friday, 3 November 2023 at 11:44:44 UTC, IGotD- wrote:On Thursday, 2 November 2023 at 22:20:41 UTC, Imperatorn wrote: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.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