On Sunday, 14 December 2014 at 20:44:17 UTC, Jacob Carlborg wrote:
> On 2014-12-14 09:37, Manu via Digitalmars-d wrote:
>
>> They immediately made comments about goto-definition not working, and
>> auto-completion not working reliably.
>
> I'm curious to know which tools they used to get autocompletion and go-to-definition to work with JavaScript.

On my area of work, for example Netbeans.

https://netbeans.org/features/html5/index.html

http://wiki.netbeans.org/NewAndNoteworthyNB80#JavaScript

https://netbeans.org/kb/73/ide/javascript-editor.html

Visual Studio Web Tools and InteliJ provide similar features.

Eclipse is quite bad in comparison.

--
Paulo

On Sunday, 14 December 2014 at 15:03:27 UTC, Sönke Ludwig wrote:

> Lastly, when judging all these things, please always try to remember that almost all the work that goes into D (and vibe.d) is non-profit and everyone usually only contributes what (s)he is missing. If I would get payed through a support contract for my work on vibe.d, I could adjust my priorities to suit the requirements of others more, but like this I still have to somehow make sure to be able to pay my bills and can't just work full time to help other (commercial) projects (although I always try to help as far as possible).

Sonke, Can you advise how much a support contract for a individual or company seriously interested in using vibe.d might cost ?

On 12/14/2014 1:00 PM, Kiith-Sa wrote:
> I occasionally try to push minor doc fixes but currently I'm rather swamped, may
> do some work on that next summer.

Any help is appreciated, even small things.

On Sunday, 14 December 2014 at 18:50:44 UTC, Sean Kelly wrote:
> On Sunday, 14 December 2014 at 18:25:26 UTC, Joakim wrote:
>> On Sunday, 14 December 2014 at 17:09:31 UTC, Paulo Pinto wrote:
>>> You mean scale like Twitter and LinkedIn?
>>
>> Maybe that's why they still lose money hand over fist, especially Twitter, because of all the extra servers they have to buy. :p By comparison, Whatsapp was able to put millions of users on a server with erlang and become profitable with much less revenue:
>>
>> http://forum.dlang.org/post/bmvwftlyvlgmuehrtvlg@forum.dlang.org
>
> I don't really understand how you can simultaneously advertise Erlang and bash Java for inefficiency.  I think the core concurrency model in Erlang is really great, and it scales horizontally to great effect, but it's a bear to do TCP work in and is far less efficient than Java, let alone C++.

I'm not trying to say erlang is much more efficient in the general case than Java, as I've heard it isn't, but that they chose a language and OS that was highly optimized for their use, concurrency, and were able to scale using fewer servers as a result, as opposed to just throwing general-purpose java/.net and more servers at the problem.  Just another example of right tool for the job.

On 12/14/14, Kiith-Sa via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Example:
>
> ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack,
> Rs needles) if (isForwardRange!R && Rs.length > 0 &&
> isForwardRange!(Rs[0]) == isInputRange!(Rs[0]) &&
> is(typeof(startsWith!pred(haystack, needles[0]))) && (Rs.length
> == 1 || is(typeof(countUntil!pred(haystack, needles[1..$])))));
> ptrdiff_t countUntil(alias pred = "a == b", R, N)(R haystack, N
> needle) if (isInputRange!R &&
> is(typeof(binaryFun!pred(haystack.front, needle)) : bool));

Yeah, this is still a problem even if you're experienced with templates. It's a wall of text.

It seems like we're treating template constraints as an internal feature (just to use them to limit the possible arguments or allow overloading against other templates), but I think constraints should also be looked at as a source of documentation ("Can I call this template with this argument type? Let's see the constraint.. Whoa this is complicated..").

CSS trickery might work, but I'd prefer if we didn't beat around the bush and instead implemented constraits as separate templates if they become too complicated, e.g. turn the above to:

ptrdiff_t countUntil(alias pred = "a == b", R, Rs...)(R haystack,
Rs needles) if (canCountUntil!(pred, R, Rs);

And then the canCountUntil template would be separately documented, something like:

/** A range can be counted if:
- R is a forward range
- pred is a valid string comparison predicate, or a function that can
compare R.front with Rs.front
- ...
 */
template canCountUntil(alias pred, R, Rs...)
{
    ...
}

I mean the predicate itself kind of documents this, but it's very unreadable despite the logic making sense.

We already have things like isInputRange, and functions with constraints would likely look horrible if we copy-pasted the isInputRange implementation directly into their constraints rather than use a simple isInputRange!R check. In the same fashion the countUntil (and other functions with complex constraints) should have a helper template that's used as a constraint (like I've shown above).

On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:
> On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:
>>
>> As always, different tools for different uses.  Hopefully, D can one day be polished and mainstream enough for the enterprise use case and it will be efficient enough to be deployed at scale too. :)
>
> when will that be? windows version 25, sqlite version 1147?
...[snip]...

Perhaps when more people start helping out we'll see things progress more quickly.

D needs more than developers. Right now it needs a few volunteers who will update the web site; documentation, news feeds of recent PRs closed, recent PRs that are generating interesting discussion, roadmaps for the next 12 months indicating what core devs are working and status. Stuff that get's people excited about the next release and the future of D.

Cheers,
uri

On 12/14/2014 2:59 PM, Andrej Mitrovic via Digitalmars-d wrote:
> CSS trickery might work, but I'd prefer if we didn't beat around the
> bush and instead implemented constraits as separate templates if they
> become too complicated, e.g. turn the above to:

I think this is a fine idea.

On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
> We were trying to use vibe.d, and we encountered bugs.
>
> We were unable to build Win64 code ...

Here is exactly your problem - trying to do a web development on Windows :P Really I have never understood that counter-productive obsession with a habit that makes people differentiate development environments and production environments so much. You aren't going to use Windows servers, are you?

Well, that was somewhat off-topic grumpy remark. On actual marketing thing:

In my opinion biggest evangelist mistake everyone makes it trying to advertise D for something it simply isn't. Which inevitably fails and leaves people extremely frustrated with false advertising, like to remain there forever as a prejudice against D. Because you will have a better luck torturing kittens than try false advertising and get caught.

Idea that any D project can compete with node.js in "easy to jump in" domain is absolutely ridiculous. Attempting this is just dooming yourself to fail. Same is trying to advertise it is stable mature language - reality is it is simply not true and people will find out it sooner or later.

I think trying to sell D should look something like this "Yes, D is horrible because of X, Y and Z but here is why it doesn't matter for our case : A, B and C". Don't pretend perfection but explain trade-offs.

You won't beat node.js in getting started curve. You won't beat Java in designing huge complex systems (well, at least everyone says that). You won't beat C in raw low-level performance. But D will easily beat C in getting started curve and complex design, easily beat node.js in performance and complex design and (not-so-easily) beat Java in performance and overall versatility.

Remember the talk by Stephan (http://dconf.org/2014/talks/dilly.html) about their vibe.d usage in production and points he has made when comparing vs node.js? It was about performance, it was about resource overhead, it was about benefits of static type system and horrors of callback hell. It wasn't about how vibe.d is more shiny than node.js - and it was good.

If your colleagues went with node in the end and kept happy with it, quite likely they simple don't need advantages vibe.d can give to their project. There is no shame in it.

On 12/14/2014 5:29 PM, Dicebot wrote:
> If your colleagues went with node in the end and kept happy with it, quite
> likely they simple don't need advantages vibe.d can give to their project. There
> is no shame in it.

I also noted that none of the issues were the language itself.

On 12/14/2014 09:37 AM, Manu via Digitalmars-d wrote:
> The real trouble hit when vibe.d's WebSocket support didn't work as
> advertised; it crashed in various circumstances, and debugging was
> impossible.

Please file that one https://github.com/rejectedsoftware/vibe.d/issues.
What browser did you use?