On Wednesday, 8 February 2017 at 22:52:36 UTC, bpr wrote:
On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
Suggesting D would be an exercise in futility, unless I can create a notable project in D in my spare time that demonstrates its advantages and appeal to the masses. I tried to do this 2 years ago, but D failed me, primarily due to https://issues.dlang.org/show_bug.cgi?id=14758

I read this comment from you on another thread too, and (caveat: I'm not working in such resource constrained domains as you are) it seems sensible. It seems like it may be a good GSOC project to modify dmd as you suggest elsewhere. Have you considered trying to find someone to do that?

First, for that to happen, the D leadership would need to chime in with a plan on how they want to address this problem. Second, for me to allocate any more of my resources, I'd have to be convinced that their plan is a good solution to the problem. A -betterC switch is not at all attractive to me.

I think the D leadership are too busy addressing broader issues with the language at the moment, so this specific case is just not a high priority. Also, if it's not a priority to the them, then anyone that does attempt to work on it will just suffer an eternity in pull request purgatory.

So, I would not recommend it as a project for anyone until the D leadership decides to get involved.

I'd love to see a D3, but that seems unlikely, and more unlikely if D2 languishes. It seems though that your issues are with the implementation, not the language itself, so if you got your wishes below

Instead I suggest following through on things like
https://issues.dlang.org/show_bug.cgi?id=12270 and considering this proposal
(http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org) instead.

wouldn't you be mostly satisfied with D2?

Correct, my issue is not really with the language, but with its implementation.

Resolving issue 12270 and implementing my proposal for decoupling the compiler and druntime would prompt me to further explore D.

I'd also like to see how the recent DIP25 and DIP1000 could be leveraged. I'm looking forward to an article on the topic, or Walter's talk at DConf2017 before I dedicate any of my time to it. At first glance, however, it seems like a lot of attribute patchwork.

It's become apparent to me that D just hasn't been designed with bare-metal systems programming in mind, so I'm skeptical that even if issue 12270 and my decoupling proposal were implemented, I'd still run into other disappointments. But I'd at least be willing to give it another try, and would be thrilled to be proven wrong.


Reply via email to