Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down.

1 ==>> The VERY FIRST order of business is very simple:

When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?!

Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324".

And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D.

But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste).

D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board)

DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's are), the utilities(Dustmite, DFormat, etc) should all just work seamlessly and without hassle with each other.

What is the main problem? It's very simple: The way the paths are stored and retrieved is ancient and prone to bugs and it seems there is no clear cut way on how to get everything to find everything else. Also, versioning is not always there so even if the paths are right, the files in them may not be!

Multiple versions should be able to exist side by side(since D is ever changing and sometimes new versions simply don't work like they should, then downgrading starts causing problems).


Solution Ideas:

This is a simple problem that needs to be fixed. The installer needs to be updated to act as more of a package manager(a graphical one for us on windows) that has versioning checks and such in it. It doesn't have to be fancy, but should do a bit more work than the current on which is basically more trouble then just compressing the zip and editing sc.ini by hand.

1. A unified path/directory layout that is unambiguous and every D app can rely on.

e.g.,

\Dlang\Compilers\DMD\v2\73.01  (the v2 stuff hence forth replaced with <version>
\Dlang\Compilers\DMD\v2\main <- a junction/link to the current version, usually the latest

\Dlang\Compilers\DMD\Lib\Phobos\x86\coff\<version>
\Dlang\Compilers\DMD\Lib\Phobos\x86\omf\<version>
\Dlang\Compilers\DMD\Lib\Phobos\x64\coff<version>
\Dlang\Compilers\DMD\Lib\Phobos\x64\omf<version> (even though it doesn't exist, just empty, maybe a text file in it stating that it is not used for x64)

\DLang\Source\DMD\v...
\DLang\Docs\v...
\DLang\IDEs\VisualD\v...
\DLang\Utilities\DFormat\v...
\DLang\Utilities\DustMite\v...

\DLang\Packages\Derelict\v...
....

and so fourth. I'm not saying it has to be exactly like the one above, but the above is unambiguous. One could change compiler versions, even have a "master" compiler that simply chooses dmd, ldc, gdc, etc and could verify versions if necessary, etc.


Everything gets organized and has a place that is logical and hence easy to find, easy to use, and helps in diagnosing problems. Versioning and dependencies could be charted. (e.g., a change in one version of something doesn't necessarily break it's usage with everything else that hasn't been updated, so  we can have a table of things that work with each other based on versions. We can change, say, the version of DMD to use and the front end can consult the master version table to see what utilities that work with it and then update all the hard links.

External usages(like windows dlls, link.exe) are all handled. They are a) copied from their windows locations. b) noted the location they are copied from by adding a text file in the directory, etc) (and the installer\manager can refresh everything)

One can install on demand any aspect so everything isn't created at once.

As time evolves, this system of organization gets cleaner, clearer, and more optimal rather than the current system which seems to just be stagnant and relatively broke. It works, for the most part, but as time goes on it doesn't get any better at it's job. It's usually the same problems over and over and that is why you always get a steady stream of users having issues with D due to problems that are easily fixable with a little elbow grease and thought and a significant amount of desire to get the problem fixed[breath!]. Versioning gets better and better. If D1 had this type of system, we could simply set the version of to a D1 compiler and everything would automatically be fixed up. No trying to hunt down libraries that work with the correct versions and no using utilities that do not work with it. Then with a flick of a switch, switch back to D2. With a master site that essentially keeps the installation files in a similar configuration, the manager just retrieves them... so we don't actually have to keep old versions around. We can just download them and it will download everything required and their proper versions.

On 2017-06-16 05:53, Mike B Johnson wrote:
> Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down.
> 
> 1 ==>> The VERY FIRST order of business is very simple:
> 
> When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?!
> 
> Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324".
> 
> And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D.
> 
> But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste).
> 
> D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board)
> 
> DMD, LDC, GDC, Visual D, Coedit(or whatever the other main IDE's are), the utilities(Dustmite, DFormat, etc) should all just work seamlessly and without hassle with each other.
> 
> What is the main problem? It's very simple: The way the paths are stored and retrieved is ancient and prone to bugs and it seems there is no clear cut way on how to get everything to find everything else. Also, versioning is not always there so even if the paths are right, the files in them may not be!
> 
> Multiple versions should be able to exist side by side(since D is ever changing and sometimes new versions simply don't work like they should, then downgrading starts causing problems).
> 
> 
> Solution Ideas:
> 
> This is a simple problem that needs to be fixed. The installer needs to be updated to act as more of a package manager(a graphical one for us on windows) that has versioning checks and such in it. It doesn't have to be fancy, but should do a bit more work than the current on which is basically more trouble then just compressing the zip and editing sc.ini by hand.
> 
> 1. A unified path/directory layout that is unambiguous and every D app can rely on.
> 
> e.g.,
> 
> \Dlang\Compilers\DMD\v2\73.01  (the v2 stuff hence forth replaced with <version>
> \Dlang\Compilers\DMD\v2\main <- a junction/link to the current version, usually the latest
DVM [1] is doing some of this.

[1] https://github.com/jacob-carlborg/dvm

-- 
/Jacob Carlborg

> DVM [1] is doing some of this.
>


Cool, does it keep things well organized and deals with windows issues(link.exe., dlls, etc) or just uses the "D way" which is a hairball?

On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote:
> DVM [1] is doing some of this.
>
> [1] https://github.com/jacob-carlborg/dvm

Might it not be better when some of this is actually part of D?

- Multi-version support
- Integrated all the tools so editors know/can rely on them. I have seen this topic a few times reading here.
- Editor support like half working in a lot of cases
- ...

There are always tools out there to "fix" some issues with D but Mike does have a point in stating that everything feels fragmented.

/++

DMD / LDC are totally different installations. LDC requiring different setup. LDC is frankly the default if you need real performance but the way its developed / published / talked about, its a side project not a main part of D. And because of that LDC feels like it always needs to cache-up to D mainline.

Ifs ironic that i needed to use:

dub --compiler=C:\D2\bin\ldc2.exe

To get ldc to work...

If i take a look at Rust ... RustUp great installer, multi platform support, great cross compiling support ( still some issue with dependencies ). Go has the same great cross platform compile support. But D it feels like a struggle to figure out.

Why not publishing Dmd and LDC together as one package, one installation, one version.

/++

Why is dcd, dfmt, dscanner, not part of the base installation of D??? Webfreak wrote workspace-d and is now writing serve-d to combine code-d and the rest. But its again a side project. Its odd there is no default language server protocol for D and it needs a 3th party developer to implement it and then maintain it outside of D again.

So if webfreak gets too busy with life, a breaking change happens in D, there goes the support. Like with many 3th party plugins ...

How about file watching, i know there is a D plugin that monitors your directory and allows for recompiling ( most languages have a feature like this ) but again, its 3th party not part of D mainline, despite it being darn handy.

D is indeed way too fragmented. Clearly a lot of good developers but the way its handled, it feels like DMD and Phobos are the only focus. And all the rest is side or not integrated. This is just my feeling. And when resources are split like this, it is indeed much more difficult for new users to get going.

On Friday, 16 June 2017 at 10:12:06 UTC, Wulfklaue wrote:
> On Friday, 16 June 2017 at 06:58:57 UTC, Jacob Carlborg wrote:
>> DVM [1] is doing some of this.
>>
>> [1] https://github.com/jacob-carlborg/dvm
>
> Might it not be better when some of this is actually part of D?

There is an official D installer for Posix systems that can handle multiple compilers and all versions quite well.
IIRC does dvm only support DMD?

> - Multi-version support
> - Integrated all the tools so editors know/can rely on them. I have seen this topic a few times reading here.

I think you are just complaining about Windows. Everything is nicely packaged under Linux, Posix and OSX.

> - Editor support like half working in a lot of cases

The beauty of D is that you don't need a fancy editor.

> - ...
>
> There are always tools out there to "fix" some issues with D but Mike does have a point in stating that everything feels fragmented.
>
> /++
>
> DMD / LDC are totally different installations. LDC requiring different setup.

Really?

curl i.dlang.io | bash -s dmd
curl i.dlang.io | bash -s dmd-2.072.2
curl i.dlang.io | bash -s dmd-newCTFE
curl i.dlang.io | bash -s dmd-nightly
curl i.dlang.io | bash -s ldc
curl i.dlang.io | bash -s ldc-beta
curl i.dlang.io | bash -s ldc-1.1.0
curl i.dlang.io | bash -s gdc


> LDC is frankly the default if you need real performance but the way its developed / published / talked about, its a side project not a main part of D. And because of that LDC feels like it always needs to cache-up to D mainline.

Are there any features between 2.073.2 (latest LDC beta) and 2.074.1 that you actually miss?

> Ifs ironic that i needed to use:
>
> dub --compiler=C:\D2\bin\ldc2.exe
>
> To get ldc to work...

--compiler=ldc2 works very well for me.

> If i take a look at Rust ... RustUp great installer, multi platform support, great cross compiling support ( still some issue with dependencies ). Go has the same great cross platform compile support. But D it feels like a struggle to figure out.
>
> Why not publishing Dmd and LDC together as one package, one installation, one version.

Because the top contributors to DMD are unfamiliar with the LDC codebase. However, there are ongoing efforts to make the frontend accessible as a library.

> /++
>
> Why is dcd, dfmt, dscanner, not part of the base installation of D???

Because there is a very easy way to fetch & build them since DUB is part of the release:

dub fetch dscanner
dub build dscanner

There is even a DUB API that tools can use. Too complicated?

> Webfreak wrote workspace-d and is now writing serve-d to combine code-d and the rest. But its again a side project. Its odd there is no default language server protocol for D and it needs a 3th party developer to implement it and then maintain it outside of D again.
>
> So if webfreak gets too busy with life, a breaking change happens in D, there goes the support. Like with many 3th party plugins ...

Don't forget that D is an open source project driven by volunteers.

> How about file watching, i know there is a D plugin that monitors your directory and allows for recompiling ( most languages have a feature like this ) but again, its 3th party not part of D mainline, despite it being darn handy.

Because there's​ only so much that can be in a standard library. It's way to thick imho anyways. What's wrong with using a DUB package?
If it is that common to your work, you can add the project to you D include directory.

> D is indeed way too fragmented. Clearly a lot of good developers but the way its handled, it feels like DMD and Phobos are the only focus. And all the rest is side or not integrated. This is just my feeling. And when resources are split like this, it is indeed much more difficult for new users to get going.

Yes because tools come and go whereas a standard library or a package manager stays. With the limited volunteers time there's only so much that can be done.
And in your free time, you usually work on problems that are interesting to you?

On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
> Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down.
>
> [...]

I don't know what is so hard about tar -zxvf dmd.XYZ.tar.xz or unzip dmd.XYZ.zip. Am I missing something?

Perhaps rather than developing a wall of text maybe you could spend the time and energy learning how to compile and link code using an actual compiler instead of an IDE framework. You would then have the skills to use D anywhere with/without the flavour of the month IDE.

bye,
lobo

On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
>
> When a new user goes to start using D for the first time, D is a PITA to get working! Don't believe me?!?!
>
> Just try getting D installed on all 3 major systems for DMD, LDC, GDC, with an IDE, some utilities, possibly arm support(even though it's new and expected to have some issues), etc. The issues really start popping up when you are trying to use x86 + x64. Library issues that result in strange error messages instead of "This compiler is not compatible with the phobos v2.4324".
>
> And guess what? This happens to regular users too! They either. A) know how to fix them from fixing them in the past or helping others(so it doesn't count because the problem still exists) or B) have a specific setup that happens to avoid the major issues(e.g., just use linux x86) then act like there isn't any problems with D.
>
> But no one wants to work on the part of D that deals with these problems cause it's boring and most "experts" can deal with the problems in a few mins to a few hours... doesn't seem like a huge waste of time(even though it is, since it's a waste).

I'm going to summarize this as "D has issues that aren't likely to be worked on any time soon by the core team".
It boils down the following (and I write this every time I see this gets posted): People working on (and with) D for free are already invested in things they are interested in. Your choices are
- Invest time to work on these yourself (-> directly leads to results)
- Pay someone to work on these (-> should directly lead to results unless you get swindled)
- Write about it here (-> raise awareness, may lead to results, but unlikely)
While I can understand your frustration (and share it for a couple of issues) and raising awareness for issues is a good thing, the third of these options is (historically speaking) unlikely to yield results by itself in this community as people's time is limited. If you want these issues dealt with, go with option one or two.

>
> D needs to just work! Library errors, setup problems, IDE integration should just work! It seems the changes of it working are about 75-85%... that IS LOW! It should be 99%. (And I'm talking across the board)

Everything *I* need works well enough (and I'm fairly convinced it is the same for the majority of D users, though that is speculation). If you want something fixed, do it yourself or pay someone to do it.

On Friday, 16 June 2017 at 10:38:44 UTC, Seb wrote:
> There is an official D installer for Posix systems that can handle multiple compilers and all versions quite well.
> IIRC does dvm only support DMD?

Good for the poxis platform set ... but D is used on more then only linux and osx.

> I think you are just complaining about Windows. Everything is nicely packaged under Linux, Posix and OSX.

And that makes the point wrong? No it does not ...

> The beauty of D is that you don't need a fancy editor.

That is a straw man argument...

Every language can be more productive with a editor, especially when people first learn the language. Lets not turn this into a editor/ide vs ... discussion. You got your preference, that is clear by now.

> Really?
>
> curl i.dlang.io | bash -s dmd
> curl i.dlang.io | bash -s dmd-2.072.2
> curl i.dlang.io | bash -s dmd-newCTFE
> curl i.dlang.io | bash -s dmd-nightly
> curl i.dlang.io | bash -s ldc
> curl i.dlang.io | bash -s ldc-beta
> curl i.dlang.io | bash -s ldc-1.1.0
> curl i.dlang.io | bash -s gdc

Thanks but again besides the point. The Original poster is referring to the experience for new users.

Do you expect every user to know Linux commands? Do you expect them to run Linux?

The fact that your over emphasizing on this, clearly shows that there is a gap in D there multi-platform support.

Thanks for the information. Its useful for me but that is NOT THE POINT!

> Are there any features between 2.073.2 (latest LDC beta) and 2.074.1 that you actually miss?

Up to recently Dmd and Ldc used to be much more separated in there future set.

And please do tell ... having 2.073.2 vs 2.074.1 version difference may not be a lot but its still not a single platform support.

Bugs or issues solved in DMD 2.074.1 can hamper somebody who is cross compiling for production. And visa versa.

Is it that difficult to have both versions synchronized and released as one package? Why the push back to even mentioning this.

> --compiler=ldc2 works very well for me.

Nice to know, yet, that did not work in my case and it needed the path.

> Because the top contributors to DMD are unfamiliar with the LDC codebase. However, there are ongoing efforts to make the frontend accessible as a library.

Good to know...

> Because there is a very easy way to fetch & build them since DUB is part of the release:
>
> dub fetch dscanner
> dub build dscanner

Again, this is straw man argumentation.

This assumes knowledge of dub, knowledge of the tools used, it assume the editor can interact and find the builds. And frankly, running it like that also pollutes a project ( seen it, done it, got the medal ).

Read the freaking original poster his text. He is frustrated that for new users, maybe people with little to no background D is simply a mess.

I pointed out that Rust and Go are WAY more easy to setup everything and interact with advanced features because they integrated a lot more.

And on a side note: There is nothing more fun as running into a bug with dfmt or some other third party plugin because a change that happened in dmd.

Example: latest DMD, a change happened, plugin does not compile. Now please do tell how a totally new user will find his way around? They will post here, get some crispy comment and maybe leave. Or hell, they may not even post here.

> Don't forget that D is an open source project driven by volunteers.

So do you and every other person remind the people who point out issues. And the point is? Well, its all volunteer project so never expect a improvement until somebody wants to fix it. Strange because Rust is highly volunteer based and yet they have a more coherent structure. So why is that? Now that is a good question...

> Because there's​ only so much that can be in a standard library. It's way to thick imho anyways. What's wrong with using a DUB package?

What i am talking about is not part of the standard library, hell, it has nothing to do with the library at all. Its part of the standard tool set. Total different things...

> If it is that common to your work, you can add the project to you D include directory.

Again ... very, VERY unclear how and what is possible in D. Sure, i can figure it things out but it takes time. And the next guy also needs to put time into this. And the next guy...

> Yes because tools come and go whereas a standard library or a package manager stays. With the limited volunteers time there's only so much that can be done.
> And in your free time, you usually work on problems that are interesting to you?

Maybe that is the same reason why D has a issue drawing in new non-C/C++ developers? Maybe because too many people live in there high tower assuming its easy for everybody else.


And no offense but some responses here feel like: "Hey somebody pointed out a problem. Lets jump on this person for pointing it out".

I am already seeing the arguments that D is all about volunteers and the push back. "Hey, D is all volunteers. Why do you not do it. Well, if you do not do it, it will never happen". And round and round that discussion goes.


On Friday, 16 June 2017 at 10:55:04 UTC, Moritz Maxeiner wrote:
> Everything *I* need works well enough (and I'm fairly convinced it is the same for the majority of D users, though that is speculation). If you want something fixed, do it yourself or pay someone to do it.

Well, i do not have the time. Want me to donate? Does that solve the issue. No ... because there is no clear infrastructure in place to actually hire people to work on the language and the environment.

Pointless to even mention this, it like all the other discussions like this. People mention issue. Blow back. Heated discussions. And the people who complain give up. Those that point fingers continue living in there bubble and ... nothing changes or improves.

I do not have a issue donating money. In the process of setting up a company and maybe can support D from that angle. But i do have a issue when people react like this whenever people with good intention get blow back. The original poster his topic title is a bad choice but his points are not. Just reading the history on the mail group and you see so many time the same issues. And the exact same responses. And the exact same nothing happening because people give up.

D for me works but i like to see D also grow. When D grows, it means the language will get longer support. A bigger community is more resources. Win win for everybody. But for some reason i can not help to feel that some people are almost against this, the attitude here simply STINKS when it comes down to issues. The whole "it works for me, so how dare you complain" is really demotivating and frankly scares people away.

Hey, it works for me "not dumb dumb" but its the wast of time figuring out things that are much more easy in other languages. But that also means anybody coming with limited programming knowledge or no linux knowledge and wants to do more then a "hello world", will run into the exact time wasting issues.

But please, do shoot the messengers. Like that will help.

I am already far into my project with D but at the same time i can not help getting this nagging feeling that D has major issues beyond its base language. Mostly its community and structure. I see less of this with for instance Rust despite being a WAY younger language and audience. Its almost like D is stuck in the past, in some kind of pre-2000 C++ attitude. Like i said, maybe its me. D as a base language works but for such a old language ( lets be honest about that ), its a real struggle on the other areas beyond the language.

On Friday, 16 June 2017 at 11:50:20 UTC, Wulfklaue wrote:
> On Friday, 16 June 2017 at 10:55:04 UTC, Moritz Maxeiner wrote:
>> Everything *I* need works well enough (and I'm fairly convinced it is the same for the majority of D users, though that is speculation). If you want something fixed, do it yourself or pay someone to do it.
>
> Well, i do not have the time.

Then hire someone.

> Want me to donate?

Straw man. Donations are not the same as paying for a specific service (i.e. no contractual obligations).

> Does that solve the issue.

Yes.

> No ... because there is no clear infrastructure in place to actually hire people to work on the language and the environment.

Claiming a solution does not work because it's hard to use does not help your cause.
If you are interested in donations, there is such infrastructure, it's called the D Foundation.
If you are interested in contract work, you are correct, there is no such infrastructure;
however, there not being a ready made infrastructure for hiring does not preclude you from finding someone yourself, e.g. through the accounce newsgroup.

>
> Pointless to even mention this, it like all the other discussions like this. People mention issue. Blow back. Heated discussions. And the people who complain give up. Those that point fingers continue living in there bubble and ... nothing changes or improves.

You are deliberately inflaming a previously neutral subthread with hyperboles and a personal attack.
The matter remains simple: If you (or anyone else) has an issue, it's good (as I stated) to raise awareness for it; but if you want something done and don't want (or can't) do it yourself, you have to either convince someone else that your time is worth more than theirs, or you have to pay someone to deal with it.

>
> I do not have a issue donating money. In the process of setting up a company and maybe can support D from that angle. But i do have a issue when people react like this whenever people with good intention get blow back.

Again, you are deliberately using inflammatory speech against someone who has given the OP a rational response as to why I think doing *only* this won't help his cause.

> The original poster his topic title is a bad choice but his points are not.

Straw man. I never said anything on those points.

> Just reading the history on the mail group and you see so many time the same issues.

In the very post of mine you quote I write about stating this every time these kinds of issues pop up (which strongly implies that it does so not rarely).

> And the exact same responses.

I'm not sure why that bothers you. It would be strange to me for the same kind of issue in the same context to receive a different response.

> And the exact same nothing happening because people give up.

That is the crux of having limited human resources in a volunteer project.

> [...] But for some reason i can not help to feel that some people are almost against this, the attitude here simply STINKS when it comes down to issues. The whole "it works for me, so how dare you complain" is really demotivating and frankly scares people away.

This is the third time you are being intentionally inflammatory in a previously neutral correspondence, even utterly twisting my post into something that simply is not there.
What I wrote boils down to "It works for me, so don't expect me to fix it for you for free. I think it is the same for most others here". If that is demotivating to you, I am forced to wonder if you consider your time objectively worth more than that of others.

>
> Hey, it works for me "not dumb dumb" but its the wast of time figuring out things that are much more easy in other languages.

Fourth time you are being inflammatory, even going as far as completely inventing statements I have not made.

> But that also means anybody coming with limited programming knowledge or no linux knowledge and wants to do more then a "hello world", will run into the exact time wasting issues.

And if that bothers you enough to take action, your courses are *still* the following:
- Do the work yourself
- Hire someone to do the work
- Convince someone that their time is better spend on dealing with this than on whatever it is that interests them

>
> But please, do shoot the messengers. Like that will help.

Fifth time you are being intentionally inflammatory and trying to twist my post.
I informed the OP that I think it unlikely this will convince someone to choose to spend their free time on this, than on something else. It boggles my mind how you could possibly twist that into "shooting the messengers".

>
> I am already far into my project with D but at the same time i can not help getting this nagging feeling that D has major issues beyond its base language. Mostly its community and structure. I see less of this with for instance Rust despite being a WAY younger language and audience. Its almost like D is stuck in the past, in some kind of pre-2000 C++ attitude.

No, it's almost like Rust has a global player with its software on a significant share of human interfaceable internet devices rigorously pushing for it, pouring time, money, and a huge preexisting viral fan base into it. Like the Mozilla foundation.

> Like i said, maybe its me. D as a base language works but for such a old language ( lets be honest about that ), its a real struggle on the other areas beyond the language.

Age of a PL (beyond some initial dev time) has little effect on the viability of its ecosystem.
An even if, while D1 dates to around 2001, and Rust to around 2010 (which is not a particularly long time in the first place when compared to the competitors C and C++), D2 (which due to it's several deep changes can be considered a different language) dates to around 2007, which is a negligible difference to Rust.

On Friday, 16 June 2017 at 03:53:18 UTC, Mike B Johnson wrote:
> Seriously! D is starting to gain momentum and if things are not stabilized it's going to slow D down.
>
> [...]

All decent ideas- except for the bit about D1, as it has been deprecated- but obviously nobody has been willing to work on adding such fit and finish.  If you believe someone should volunteer their time to work on this, the obvious question is why don't you do it?  If you think there is a market for paid support that includes such polish, you could charge for it.

On the other hand, maybe D is not meant for the kind of user who needs such an easy path.  What does it matter if you set D up really easily and then can't grasp such a sprawling, lower-level language?  Perhaps _this_ is the right packaging for D right now, to keep away the kinds of casual users who would not be suited for D.

I don't have a strong opinion on that, just making an observation.  It works well for me, and having a long history of using OSS projects that are _much_ worse to set up, I can't complain. :)