Lost a new commercial user this week :(

[Chris via Digitalmars-d]

On Thursday, 18 December 2014 at 14:34:10 UTC, Manu via 
Digitalmars-d wrote:
> On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Thursday, 18 December 2014 at 10:47:56 UTC, Manu via 
>> Digitalmars-d wrote:
>>>
>>>
>>> I think you've missed my entire point.
>>> The summary is this:
>>> Tried D, tried a very popular and often hyped D 
>>> library/framework,
>>> encountered bugs. There was friction along the way which 
>>> undermines
>>> confidence, but the critical point, the thing that caused the 
>>> call to
>>> be made, was that the debugger didn't work, and we were 
>>> unable to
>>> diagnose the bug with relative ease.
>>> It's possible that wouldn't have inspired the call to be made 
>>> if it
>>> weren't for the prior friction... ie, if it were the first 
>>> point of
>>> friction, we might have persevered through that one, but the 
>>> aggregate
>>> prior to that point painted a clear picture, and that was the
>>> proverbial straw.
>>>
>>> Immaturity in the language seemed to allow for greater 
>>> tolerance than
>>> immaturity in the tooling.
>>> This is the experience I was trying to convey... which was to 
>>> be taken
>>> as a case study, that is all.
>>>
>>
>> What I'm wondering is how is it you didn't encounter this 
>> issue yourself
>> before ? If you've been using D for 6 or 7 years, and it was a 
>> small project
>> that was done in 20 to 30 lines of node.js ? So you clearly 
>> entered unknown
>> territory and expected everything to be fine, despite your 
>> experience with
>> D.
>
> Simple, I never tried to use websockets in vibe.d
> I had some past experience with vibe.d to do some web page 
> stuff, and
> my experience was practically flawless, which is why I had 
> confidence
> in it in the first place.
>
> Other common language issues that I did anticipate, I expected 
> to be
> able to work through. I did know the debugger was an issue; it 
> was
> actually my biggest fear going in. It did turn out to be the 
> thing
> that bit me in the arse!
> I just hoped/expected we wouldn't need the debugger in such a 
> small
> and simple program.
> The debugger does work okay for certain tasks, particularly if 
> you
> control your coding style and make sure it's compatible with the
> debugger. I didn't have that luxury though as I usually do, 
> since we
> were working on a foreign framework.
>
>
>> Can you link us to the issue(s) you created on Vibe.d's Github 
>> ?
>
> https://github.com/rejectedsoftware/vibe.d/issues/931
>
> I can't really articulate the problem well. Google's Native 
> Client is
> a part of the puzzle, and that's a complex environment to get 
> working.
> We tested the NaCl client against some other websocket servers 
> though,
> and the problem didn't occur.
>
> I want to try and isolate a test case if I ever get some free 
> time at work :/
>
>
> The other problem I can't isolate, it's just that the first file
> that's requested from time to time locks up the browser... if I 
> kill
> the browser, reload and refresh, the problem goes away.
> I'll also see if I can post some code that demonstrates that 
> case, but
> I have my suspicions that's client specific too.
>
>
>> We know some stuff sux. Just look at std.datetime's 
>> documentation. On my 15"
>> laptop, the links take all the screen. And this part is 
>> totally useless, as
>> no one is going to use it (beside ctrl + f, but you have to 
>> know what you
>> are looking for). Not mentioning the size of enum (just look 
>> at how much
>> space trivial enums such as "DayOfWeek" or "Month" takes).
>>
>> However, many of us lack the time and interest to fix this, as 
>> we know our
>> way around. The same goes for all the tooling/libraries, they 
>> were
>> developped, and are maintained out of one's necessity, not 
>> because "we" need
>> it.
>
> I know. I only said that there were a lot of complaints 
> relating to
> the documentation, because there were.
> Although that said, as far as I can tell, it wasn't a 
> particularly
> heavily weighting factor in the decision. Just worth noting; it 
> wasn't
> endearing to anyone.

So to sum things up

1. you blindly walked into something you had no real experience 
with, apart from some vague memory that some parts of vibed 
worked for you a while ago.

2. you knew the debugger might be an issue, if not _the_ issue, 
but chose not to test it beforehand, or couldn't test it 
beforehand, because

3. you were working on a foreign framework (and simply hoped 
things would work out fine, fingers crossed!).

These are crucial bits of information that were missing from your 
first report.

Please try to be more accurate the next time. Holding back 
crucial information gets us nowhere. It only leaves the (false) 
impression that D is completely unusable.