Lost a new commercial user this week :(

Manu via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 18 06:33:58 PST 2014


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.


More information about the Digitalmars-d mailing list