Sadly, I failed to create a new commercial D user this week, and I'm
really disappointed.
It was rejected for exactly the same practical reasons I've been saying forever.

There were a few contributing factors, but by far the most significant factor was the extremely poor Windows environment support and Visual Studio debugging experience.

We were trying to use vibe.d, and we encountered bugs.

We were unable to build Win64 code (vibe.d doesn't support Win64 it seems), and the 32bit compiler produces useless OMF output. We couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it.

The real trouble hit when vibe.d's WebSocket support didn't work as
advertised; it crashed in various circumstances, and debugging was
impossible.
vibe.d uses exceptions everywhere, which caused an office full of
C/C++ programmers to explode with terror, and Visual Studio completely
craps itself when there are exceptions being thrown.

We tried the VS debugger, and also Mago. Both presented different kinds of issues, which lead to people seriously questioning the quality of the ecosystem, if 2 out of 2 available debug tools don't work, and for different reasons.

We had to revert to running without the debugger, and trying to printf() debug, but that proved to be a massive waste of time, and caused enough distaste to the other engineers that it shattered whatever confidence I had built up in D. The decision was made to abandon ship and revert to node.js, which satisfied our needs within a couple of hours.

The result was a bunch of die-hard native C programmers, initially excited to use a native language to write a webserver, instead saying stuff like "wow, node.js just worked! that's amazing, javascript is awesome!"... and then mocking me about my D language thing.


What's the take-away here? Well, like I've been saying endlessly for years now, *first impressions matter*, and quality of tooling matters more than anything.

They made comments about the installer, where VisualD's installer
failed to remember the path that we installed DMD only moments
earlier.
They immediately made comments about goto-definition not working, and
auto-completion not working reliably.

They then made HUGE noises about the quality of documentation. The
prevailing opinion was that the D docs, in the eyes of a
not-a-D-expert, are basically unreadable to them. The formatting
didn't help, there's a lot of noise and a lack of structure in the
documentation's presentation that makes it hard to see the information
through the layout and noise. As senior software engineers, they
basically expected that they should be able to read and understand the
docs, even if they don't really know the language, after all, "what is
the point of documentation if not to teach the language..."
I tend to agree, I find that I can learn most languages to a basic
level by skimming the docs, but the D docs are an anomaly in this way;
it seems you have to already know D to be able to understand it
effectively. They didn't know javascript either, but skimming the
node.js docs they got the job done in an hour or so, after having
wasted *2 days* trying to force their way through the various
frictions presented but their initial experience with D.


I have spent months discussing D with other engineers, dropping little tidbits and details out to the floor here and there, getting people excited and jazzed to try something new, and quietly waiting for the opportunity to arise where I can suggest writing some new code in D.

I have spent months where people are coming up to me most days asking about some shit thing in C/C++ and how D does it better, to which I usually have a good answer for them, and they walk away excited.

...the moment came. I've built confidence and excitement in these people, but when their first impression is a shambles, it completely undoes all that work, and almost completely shattered their confidence.

I also feel personally hurt. I'm frequently putting my reputation on the line when I recommend D to organisations I work in, and all my colleagues. And in this case, I received a serious blow, and that's hard to swallow.


I want to see flawless debugging put on the road map as top priority.
We need a test environment for the windows installer and VS
integration that is thorough and that we can depend on.
It's 10 years overdue. We need to get this practical shit together if
people are going to take D seriously!

I think most importantly though, we need LDC! Assuming those other things come good, we need a compiler with a backend to produce the expected performance, and which integrates in a well known way with the ecosystem around it.

Currently, I understand that the only outstanding issue with LDC for Windows is the debuginfo output? I think this is mainly with the LLVM crew, but is there anything we can do to help with this?


One of the take-away quotes I think, was "D seems to be a language for
people who actively want to go and look for it, and take the time to
learn it. That's never going to be a commercial success."
It's painful to accept the truth in that statement. Go and try and
learn any other trendy language today. The homepage looks modern,
there has been professional design, testing, and there are
instructional videos recorded by a professional voice actor with that
trendy bloody upbeat ukulele music in the background that's in all
tech videos these days...

I think we need a budget for presentation, and we need to pay money and hire some professionals to make the content. Is there a kickstarter campaign here? I'll contribute for sure.

On 14/12/2014 9:37 p.m., Manu via Digitalmars-d wrote:
> Sadly, I failed to create a new commercial D user this week, and I'm
> really disappointed.
> It was rejected for exactly the same practical reasons I've been saying forever.
>
> There were a few contributing factors, but by far the most significant
> factor was the extremely poor Windows environment support and Visual
> Studio debugging experience.
>
> We were trying to use vibe.d, and we encountered bugs.
>
> We were unable to build Win64 code (vibe.d doesn't support Win64 it
> seems),

Yup, unfortunately I don't really have the knowledge or the willingness to get it. Otherwise this would have been fixed long ago.

> and the 32bit compiler produces useless OMF output. We

That has already been sorted out in master after all. So getting there.

> couldn't link against any of our existing code which was a serious
> inconvenience, but they were understanding and we worked around it.
>
> The real trouble hit when vibe.d's WebSocket support didn't work as
> advertised; it crashed in various circumstances, and debugging was
> impossible.

What I wish happened with Vibe.d is to scope it really REALLY down.
It is not a web service framework. It is a web SERVER framework.
There is a big difference such as WebSocket proberbly shouldn't even be in Vibe.d.

> vibe.d uses exceptions everywhere, which caused an office full of
> C/C++ programmers to explode with terror, and Visual Studio completely
> craps itself when there are exceptions being thrown.

Unfortunately I'm in the camp of, if exceptions don't work. Don't use Vibe.d.

> We tried the VS debugger, and also Mago. Both presented different
> kinds of issues, which lead to people seriously questioning the
> quality of the ecosystem, if 2 out of 2 available debug tools don't
> work, and for different reasons.

Debugger is asking for trouble :/

> We had to revert to running without the debugger, and trying to
> printf() debug, but that proved to be a massive waste of time, and
> caused enough distaste to the other engineers that it shattered
> whatever confidence I had built up in D. The decision was made to
> abandon ship and revert to node.js, which satisfied our needs within a
> couple of hours.
>
> The result was a bunch of die-hard native C programmers, initially
> excited to use a native language to write a webserver, instead saying
> stuff like "wow, node.js just worked! that's amazing, javascript is
> awesome!"... and then mocking me about my D language thing.
>
>
> What's the take-away here? Well, like I've been saying endlessly for
> years now, *first impressions matter*, and quality of tooling matters
> more than anything.
>
> They made comments about the installer, where VisualD's installer
> failed to remember the path that we installed DMD only moments
> earlier.
> They immediately made comments about goto-definition not working, and
> auto-completion not working reliably.

For some strange reason I have never liked VS or VisualD.

> They then made HUGE noises about the quality of documentation. The
> prevailing opinion was that the D docs, in the eyes of a
> not-a-D-expert, are basically unreadable to them. The formatting
> didn't help, there's a lot of noise and a lack of structure in the
> documentation's presentation that makes it hard to see the information
> through the layout and noise. As senior software engineers, they
> basically expected that they should be able to read and understand the
> docs, even if they don't really know the language, after all, "what is
> the point of documentation if not to teach the language..."
> I tend to agree, I find that I can learn most languages to a basic
> level by skimming the docs, but the D docs are an anomaly in this way;
> it seems you have to already know D to be able to understand it
> effectively. They didn't know javascript either, but skimming the
> node.js docs they got the job done in an hour or so, after having
> wasted *2 days* trying to force their way through the various
> frictions presented but their initial experience with D.

Agreed its rather an interesting position. But that's why there is e.g. Ali's book and TDPL to do just that teach.
This should proberbly be made into a big flashing banner, wanna learn D?, go here!

> I have spent months discussing D with other engineers, dropping little
> tidbits and details out to the floor here and there, getting people
> excited and jazzed to try something new, and quietly waiting for the
> opportunity to arise where I can suggest writing some new code in D.
>
> I have spent months where people are coming up to me most days asking
> about some shit thing in C/C++ and how D does it better, to which I
> usually have a good answer for them, and they walk away excited.
>
> ...the moment came. I've built confidence and excitement in these
> people, but when their first impression is a shambles, it completely
> undoes all that work, and almost completely shattered their
> confidence.
>
> I also feel personally hurt. I'm frequently putting my reputation on
> the line when I recommend D to organisations I work in, and all my
> colleagues. And in this case, I received a serious blow, and that's
> hard to swallow.
>
>
> I want to see flawless debugging put on the road map as top priority.
> We need a test environment for the windows installer and VS
> integration that is thorough and that we can depend on.
> It's 10 years overdue. We need to get this practical shit together if
> people are going to take D seriously!
>
> I think most importantly though, we need LDC! Assuming those other
> things come good, we need a compiler with a backend to produce the
> expected performance, and which integrates in a well known way with
> the ecosystem around it.
>
> Currently, I understand that the only outstanding issue with LDC for
> Windows is the debuginfo output? I think this is mainly with the LLVM
> crew, but is there anything we can do to help with this?
>
>
> One of the take-away quotes I think, was "D seems to be a language for
> people who actively want to go and look for it, and take the time to
> learn it. That's never going to be a commercial success."
> It's painful to accept the truth in that statement. Go and try and
> learn any other trendy language today. The homepage looks modern,
> there has been professional design, testing, and there are
> instructional videos recorded by a professional voice actor with that
> trendy bloody upbeat ukulele music in the background that's in all
> tech videos these days...
>
> I think we need a budget for presentation, and we need to pay money
> and hire some professionals to make the content. Is there a
> kickstarter campaign here? I'll contribute for sure.

No objections with presentation budget, although extending it to advertising in general might be a good idea.
Great example, how about separating out Walters website from D's? Or one Google indexed web interface to the news group.
Not to mention things like ApplyYourDLang (don't have time to do it / waiting for other projects).

If only we had the money.
Unfortunately I wish I could do a lot more.

I personally tried to improve the web situation, still waiting on a PR for another round of review/pull before I can even consider putting up the next version of Cmsed.
Now I'm back to the GUI situation. Maybe if I can get a Google Material design working, we can get some free advertising.

And I have to get a job sometime next month (graduated). I'm trying.

On Sun, 14 Dec 2014 22:13:13 +1300
Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Now I'm back to the GUI situation.
talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD and alot of other projects. they suck. they suck badly. there was a great project once, "Harmonia", but it is dead. DWT suck being java-rooted, and java GUI toolkits are piles of crap. other suck being just a wrappers. there is no GUI toolkit that utilises some kind of markup language, constraint engine (cassowary, anyone?), easy FX without writing boilerplate code, theming and not being a fscking wrapper.

yes, i know: "if you want to have something, stop ranting and just do it!" yet i have alot of other hobby projects and only 24 hours in a day. poor me.

On Sun, 14 Dec 2014 11:24:30 +0200
ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Sun, 14 Dec 2014 22:13:13 +1300
> Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> > Now I'm back to the GUI situation.
> talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD and alot of other projects. they suck. they suck badly. there was a great project once, "Harmonia", but it is dead. DWT suck being java-rooted, and java GUI toolkits are piles of crap. other suck being just a wrappers. there is no GUI toolkit that utilises some kind of markup language, constraint engine (cassowary, anyone?), easy FX without writing boilerplate code, theming and not being a fscking wrapper.
> 
> yes, i know: "if you want to have something, stop ranting and just do it!" yet i have alot of other hobby projects and only 24 hours in a day. poor me.

p.s. sorry for me being rude. DWT, GtkD and others are great project of great value. it's not about "their authors doing wrong things", that's about "i want something completely different!"

On 14/12/2014 10:27 p.m., ketmar via Digitalmars-d wrote:
> On Sun, 14 Dec 2014 11:24:30 +0200
> ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On Sun, 14 Dec 2014 22:13:13 +1300
>> Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> Now I'm back to the GUI situation.
>> talking about GUI toolkits. there is NONE. yep, i know about DWT, GtkD
>> and alot of other projects. they suck. they suck badly. there was a
>> great project once, "Harmonia", but it is dead. DWT suck being
>> java-rooted, and java GUI toolkits are piles of crap. other suck being
>> just a wrappers. there is no GUI toolkit that utilises some kind of
>> markup language, constraint engine (cassowary, anyone?), easy FX
>> without writing boilerplate code, theming and not being a fscking
>> wrapper.
>>
>> yes, i know: "if you want to have something, stop ranting and just do
>> it!" yet i have alot of other hobby projects and only 24 hours in a
>> day. poor me.
>
> p.s. sorry for me being rude. DWT, GtkD and others are great project of
> great value. it's not about "their authors doing wrong things", that's
> about "i want something completely different!"

Yeah they are great projects.
But they won't ever be what I'm looking for.

Personally?
- I want a gui toolkit that is accelerated e.g. OpenGL.
- That can be layered drawn on top of other OpenGL content.
- Completely configurable at runtime e.g. change of shaders.
- Centralized themeing.
- That works on all major platforms without heartache.

But here's the thing about guis in general.
Gui toolkits are not really designed to work with OpenGL like this.

If I want to fix this, I know I can't go around designing the controls for example. Luckily Google has already done this! Even defined default themes, and how controls should be drawn.

Now with how I want a gui toolkit to work, it has a lot of benefits.
First off, before I can even create a window, well I need a windowing library. Hello Devisualization.Window.

Next, okay I can create a window and a context as needed.
What about doing some actual drawing? Devisualization.Util:OpenGL

So drawing for OpenGL is easy, but that window could really do with an icon.. Devisualization.Image
Now lets draw some text! Devisualization.Font

Okay, now we are ready for actually ready for controls. Or are we? Nope!
Need a scenegraph to instruct when to draw each control. Devisualization.Scenegraph

Next step, lets start the actual controls! Well actually.. we already know we have separated out coordinates from events thanks to the scenegraph. So how about a scenegraph with eventing support.

Noticing something? That's about quarter of a game engine stack already made. Before even having GUI controls actually being used.
Highly modular and implementation replaceable, portable.

I'm already exhausted before even considering sound.
Also don't forget the colour paletted provided from Google is in either Photoshop or Illustrator formats. So if you want to use them.. hello parser (already made, Devisualization.Util:photoshop_aco).

On Sun, 14 Dec 2014 22:52:59 +1300
Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > p.s. sorry for me being rude. DWT, GtkD and others are great project of great value. it's not about "their authors doing wrong things", that's about "i want something completely different!"
> 
> Yeah they are great projects.
> But they won't ever be what I'm looking for.
> 
> Personally?
> - I want a gui toolkit that is accelerated e.g. OpenGL.
> - That can be layered drawn on top of other OpenGL content.
> - Completely configurable at runtime e.g. change of shaders.
> - Centralized themeing.
> - That works on all major platforms without heartache.
> 
> But here's the thing about guis in general.
> Gui toolkits are not really designed to work with OpenGL like this.
GUI toolkits are not really designed. that is. a good GUI toolkit should be able to use any backend the end user want. DirectFB? OpenGL? custom framebuffer library? anything, it should not matter at all.

the abstraction GUI toolkint using should be designed like X server. want anything? ask the underlying layer to do that. pixmap with gradient? don't do that in control painting code, ask the underlying pixmap layer to do that. want text output? don't do that, use the underlying layer that does ALL text rendering. and so on. this way GUI toolkit can use any acceleration the underlying layer can provide. and writing new control is a matter of compositing some high-level calls.

and if we'll go to the design stage, we can find markup language useful. with markup language and constraint engine we moving our rendering code even further away. thus we need two layers: basic rendering engine that can draw pixels, and markup processing engine that convert our declarative GUI description to basic operations.

and then comes the things like OpenGL, shaders and so on. on the lower level, which can be controlled from markup. do we have only framebuffer? ok, ignore advanced styling and degrate to that. modern OpenGL with shaders? ok, pass the necessary info down the pipe.

that's where Devisualisation comes into play. it provides mechanics we need, with simple and well-defined interface. what we also need is high-level engine that will convert our declarative GUI descriptions to low-level calls. HTML is not the best language to build GUIs, but the overall way Harmonia takes looking fine. declarative language for high-level descriptions and translation layer for low-level calls.

On 14/12/2014 11:15 p.m., ketmar via Digitalmars-d wrote:
> On Sun, 14 Dec 2014 22:52:59 +1300
> Rikki Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>>> p.s. sorry for me being rude. DWT, GtkD and others are great project of
>>> great value. it's not about "their authors doing wrong things", that's
>>> about "i want something completely different!"
>>
>> Yeah they are great projects.
>> But they won't ever be what I'm looking for.
>>
>> Personally?
>> - I want a gui toolkit that is accelerated e.g. OpenGL.
>> - That can be layered drawn on top of other OpenGL content.
>> - Completely configurable at runtime e.g. change of shaders.
>> - Centralized themeing.
>> - That works on all major platforms without heartache.
>>
>> But here's the thing about guis in general.
>> Gui toolkits are not really designed to work with OpenGL like this.
> GUI toolkits are not really designed. that is. a good GUI toolkit
> should be able to use any backend the end user want. DirectFB? OpenGL?
> custom framebuffer library? anything, it should not matter at all.

Agreed and I know. I'm using OpenGL as an example. You'll notice heavily that I abstract interface from implementation to the point of there is literally a subpackage called opengl for the OpenGL implementation.

> the abstraction GUI toolkint using should be designed like X server.
> want anything? ask the underlying layer to do that. pixmap with
> gradient? don't do that in control painting code, ask the underlying
> pixmap layer to do that. want text output? don't do that, use the
> underlying layer that does ALL text rendering. and so on. this way GUI
> toolkit can use any acceleration the underlying layer can provide. and
> writing new control is a matter of compositing some high-level calls.
>
> and if we'll go to the design stage, we can find markup language
> useful. with markup language and constraint engine we moving our
> rendering code even further away. thus we need two layers: basic
> rendering engine that can draw pixels, and markup processing engine
> that convert our declarative GUI description to basic operations.
>
> and then comes the things like OpenGL, shaders and so on. on the lower
> level, which can be controlled from markup. do we have only framebuffer?
> ok, ignore advanced styling and degrate to that. modern OpenGL with
> shaders? ok, pass the necessary info down the pipe.
>
> that's where Devisualisation comes into play. it provides mechanics we
> need, with simple and well-defined interface. what we also need is
> high-level engine that will convert our declarative GUI descriptions to
> low-level calls. HTML is not the best language to build GUIs, but the
> overall way Harmonia takes looking fine. declarative language for
> high-level descriptions and translation layer for low-level calls.

Agreed, I hate to say it, because I'm basing off of Google Material design, I would have to use what ever Google does on Android out of pure ease of porting.
So its not something I'm able to create new. Just a new implementation.

On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
>
> Sadly, I failed to create a new commercial D user this week,  and I'm really disappointed.
> It was rejected for exactly the same practical reasons I've  been saying forever.
>
> There were a few contributing factors, but by far the most significant
> factor was the extremely poor Windows environment support and Visual Studio debugging experience.

I find exactly the same issue for every developer that I'm moving from C++ to D under Windows: the bar is very high here.

> We were trying to use vibe.d, and we encountered bugs.

We are using Vibe also here in Milan: it's maintained since a long time, and it has plenty of adopters, but... it's just too big.
Sönke is doing a remarkable job, but, for example, I've a mail server in production using vibe with an assert turned into an hard exit && restart: I was simply unable to debug it.

And it's also very picky about what compiler to use to have a proper build, at least, lately.
Actually I'm on a branch trying to have it run with master, as I need async-socker and C++ support for a product... *sigh*

> We were unable to build Win64 code (vibe.d doesn't support  Win64 it seems), and the 32bit compiler produces useless OMF output. We
> couldn't link against any of our existing code which was a serious inconvenience, but they were understanding and we worked around it.

I tend to agree about debugging, we also need to keep a Win32 application live, and it's a mess.
I know that there's some improvement over that lately, but practically we are developing and debugging it in linux and just running the unittests in Win32.

Regarding Vibe, why aren't you using linux for such a job? I think that's the right tool for that kind of services, and life is more easier in that land.

> The real trouble hit when vibe.d's WebSocket support didn't work as
> advertised; it crashed in various circumstances, and debugging was impossible.
> vibe.d uses exceptions everywhere, which caused an office full  of
> C/C++ programmers to explode with terror, and Visual Studio completely craps itself when there are exceptions being thrown.

Yep, I can understand, and the documentation does not help a lot, I would say.
I think vibe is simply too ambitious: it should take the road of being split, with some pieces being somehow absorbed by Phobos (like the new concurrency).
I'm planning to switch to Etienne package for simple socket applications...

> We tried the VS debugger, and also Mago. Both presented  different
> kinds of issues, which lead to people seriously questioning the
> quality of the ecosystem, if 2 out of 2 available debug tools don't work, and for different reasons.
>
> We had to revert to running without the debugger, and trying to
> printf() debug, but that proved to be a massive waste of time, and caused enough distaste to the other engineers that it shattered
> whatever confidence I had built up in D. The decision was made to abandon ship and revert to node.js, which satisfied our needs within a couple of hours.

That's the point...
I can simply impone to adopt D, because I've the power of doing that, but trying to evangelize bottom-up it seems to me a via crucis...

> The result was a bunch of die-hard native C programmers, initially
> excited to use a native language to write a webserver, instead saying stuff like "wow, node.js just worked! that's amazing, javascript is awesome!"... and then mocking me about my D language thing.

*sigh*, but hey: I really hate Javascript (but I'm using it with Meteor...)

> They then made HUGE noises about the quality of documentation.
<snip>

I don't agree here: just go with books.
Thanks to Ali, Andrej, Philippe and Adam for covering well that field.

> It's painful to accept the truth in that statement. Go and try  and
> learn any other trendy language today. The homepage looks modern,
> there has been professional design, testing, and there are
> instructional videos recorded by a professional voice actor with that trendy bloody upbeat ukulele music in the background that's in all tech videos these days...
>
> I think we need a budget for presentation, and we need to pay money
> and hire some professionals to make the content. Is there a kickstarter campaign here? I'll contribute for sure.

I disagree here: the most beautiful advertising for D are concrete success stories out in the wilds.
So first, it needs to stop loosing commercial adopters: why they dropped it, that's the most valuable feedback for the D community.

And, IMHO, in THAT specific case, it was:

- debugging experience must be top class
- async-io as a "basic" operation, choosing vibe as the 'de-facto' most suitable solution, it's not available for neither the big-two, Lin/Win (OS X is a no-go platform for D until the support to ObjC will be merged).

---
/Paolo

Thanks for the feedback.

On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
> We were unable to build Win64 code (vibe.d doesn't support Win64 it
> seems), and the 32bit compiler produces useless OMF output. We
> couldn't link against any of our existing code which was a serious
> inconvenience, but they were understanding and we worked around it.

Did you try the new 32-bit COFF support in dmd from git?

> The result was a bunch of die-hard native C programmers, initially
> excited to use a native language to write a webserver, instead saying
> stuff like "wow, node.js just worked! that's amazing, javascript is
> awesome!"... and then mocking me about my D language thing.

"die-hard native C programmers" who are fine with javascript?  Is it one or two orders of magnitude slower than vibe.d? ;) I know v8 is fast for javascript, but it has to be significantly slower than C and D.

> What's the take-away here? Well, like I've been saying endlessly for
> years now, *first impressions matter*, and quality of tooling matters
> more than anything.
---snip---
> I want to see flawless debugging put on the road map as top priority.
> We need a test environment for the windows installer and VS
> integration that is thorough and that we can depend on.
> It's 10 years overdue. We need to get this practical shit together if
> people are going to take D seriously!
---snip---
> One of the take-away quotes I think, was "D seems to be a language for
> people who actively want to go and look for it, and take the time to
> learn it. That's never going to be a commercial success."
> It's painful to accept the truth in that statement. Go and try and
> learn any other trendy language today. The homepage looks modern,
> there has been professional design, testing, and there are
> instructional videos recorded by a professional voice actor with that
> trendy bloody upbeat ukulele music in the background that's in all
> tech videos these days...

There has never been a successful open source project without significant commercial support, going from linux to perl on down the line.  D's commercial support consists of some Facebook bounties, Sociomantic throwing out huge pulls occasionally that never get merged, and companies like EMSI chipping in where they can.  D will never have "commercial success" through the higher quality tooling and presentation you are calling for without more significant commercial involvement to fund it, period.

Right now, D is bleeding-edge technology.  You have to know how to stay away from the chipper blades of the D chainsaw or it could cut your arm open and you could bleed out.  Not a problem for hobbyists, but a big problem for companies, who are used to all the rough edges being sanded down and paying through the nose for such support.  If decision-makers at companies are hoping to get such polished work for free from a volunteer-oriented OSS project, they should have their heads examined.

On Sunday, 14 December 2014 at 09:13:20 UTC, Rikki Cattermole wrote:
> Great example, how about separating out Walters website from D's? Or one Google indexed web interface to the news group.

Great idea, I mentioned this before and nothing was done:

http://forum.dlang.org/post/lqpwiaqeyartbsokdlnt@forum.dlang.org

What's especially embarrassing is the old web archive will often garble posts and render them unreadable.

On 14/12/2014 11:36 p.m., Joakim wrote:
> On Sunday, 14 December 2014 at 09:13:20 UTC, Rikki Cattermole wrote:
>> Great example, how about separating out Walters website from D's? Or
>> one Google indexed web interface to the news group.
>
> Great idea, I mentioned this before and nothing was done:
>
> http://forum.dlang.org/post/lqpwiaqeyartbsokdlnt@forum.dlang.org
>
> What's especially embarrassing is the old web archive will often garble
> posts and render them unreadable.

IMO its an PR disaster. I wonder if somebody would be willing to lend Walter a hand with some redesigning. Although I think it would be a tough sell.