Lost a new commercial user this week :(

[Rikki Cattermole via Digitalmars-d]

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.