On 18 December 2014 at 23:52, Mathias LANG via Digitalmars-d <digitalmars-d@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.