On Monday, 15 December 2014 at 11:42:31 UTC, ponce wrote:
> On Monday, 15 December 2014 at 10:46:30 UTC, Dicebot wrote:
>>
>> I don't plan it and don't realistically ever expect it. Considering the fact that game development industry is traditionally one of the worst in contributing upstream I also don't have any motivation to convince them adopt D.
>>
>> If there ever appears a game development company / community interested in _investing_ into programming language that would be totally different story but also irrelevant to enterprise culture you refer to.
>
> We talk a lot of game developers here, and it's an interesting target but there are many other native programmers stuck with C++ and often unable to use anything else, in the many niches of the world.

What I mean is that the very approach of "how are you going to sell D to X" is doomed to fail because when there is no real product to sell. Proper question would be "how are you going to invite X to collaborate on D" and with such mentality it is only practical to think about interests of people that are expected to give something back.

At some point I have hoped that Facebook would take over D as commercial project but this train has long been gone by now. I consider is good platform for tinkerers, for those willing to take the risk and go for in-house innovation - nothing more, nothing less.

On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via Digitalmars-d wrote:
> 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.

Comparing node.js to D? You probably speak about vibe, not D?

> 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."

O_O Huh? Your team really didn't learn C++?

On Sunday, 14 December 2014 at 08:37:36 UTC, Manu via
Digitalmars-d wrote:

> We were unable to build Win64 code (vibe.d doesn't support Win64 it
> seems), and the 32bit compiler produces useless OMF output. We
> couldn't link against any of our existing code which was a serious
> inconvenience, but they were understanding and we worked around it.

I had the same situation in my work half year ago.

> 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.

+1, LDC is very good backend.

DMD has commutative floating point optimisation.
So I can not use it for some math functions :-(, for example for
fsum or ported Netlib routines.
fsum: https://github.com/D-Programming-Language/phobos/pull/2513

On Monday, 15 December 2014 at 11:32:30 UTC, Atila Neves wrote:
>> My personal preference is still for C++ done in a similar manner as vibe.d as I think it's the sweet spot between ease of use and scalability provided you have a talented team, but I've seen Java be used successfully for servicing hundreds of millions of users with a high concurrent throughput.
>
> So, boost asio then? Miles away from the ease-of-use of vibe.d.

No, the vibe.d model in C++ using boost coroutines.

On 2014-12-15 10:13, Walter Bright wrote:

> Please file as an enhancement request in bugzilla. Suggestions in the
> n.g. are likely to be forgotten.

It looks like that has already been filed: https://issues.dlang.org/show_bug.cgi?id=13676

-- 
/Jacob Carlborg

On 12/15/14 12:10 AM, Manu via Digitalmars-d wrote:
> On 15 December 2014 at 07:19, Nick B via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> 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 ?
>
> Good point, I think you should really put a price on commercial
> support if you want it to be taken seriously.
> There are lots of companies that wouldn't seriously consider it if it
> DIDN'T cost them some money. If they don't pay any money, it doesn't
> look legit or professional ;)

OH, it's not that AT ALL.

If I base my company, with real investors and people to be employed, on someone's code, and I cannot motivate the developers to support me with money, then I am in a shaky situation. It's not the lack of professionalism, it's the "I can't fix this, and I can't get the author to fix it, so we just have to sit on our thumbs until they do, or hire a team to figure out how to do it."

Note, this is not in relation to vibe.d, as we don't use it here, just a general view from someone who has used a "near-free" project and paid the developer to fix some issues/add features. The cost is so much lower than me figuring it out myself.

-Steve

On 12/15/2014 7:36 AM, Jacob Carlborg wrote:
> It looks like that has already been filed:
> https://issues.dlang.org/show_bug.cgi?id=13676

Thanks!

This is just my $0.02, not to ask for anything specific, but to add to the cross-section of perspectives on this topic, to whom it may concern:

A colleague and I are writing a framework for building and managing complex simulations and chose to implement in D for the modeling power that the template system brings, which allows us to make an expressive and fairly performant API that is also flexible and easily refactored thanks to static assert and unittest...

But we keep getting hamstrung by bugs; hitting compiler segfaults during template metaprogramming is a very common occurrence, and sometimes UFCS fails. We continue to make progress but lose a lot of time finding workarounds for apparently valid but noncompiling code. We are hoping that with the increased interest in D lately, the implementation will stabilize, but we are nervous about the long-term prospects.

This is a risk we knowingly undertake in exchange for the aforementioned advantages. A lot of cool stuff is possible with D that we can't do in other languages but I constantly work with the fear that we'll stumble upon some compiler bug in 6 months time that we can't find a way around. (I originally tried to write this system in C++ and I dread the idea of returning to it.)

One of our target use-cases is gaming, and to this end we hope that the difficulty we've had in getting D environments working in Windows will be alleviated soon so that we can confidently target that platform.

As typical college students (I am a senior, partner is recent grad) we can't afford to put up bounties or contract anyone but we put up bug reports when we can (this will be easier when dub dustmite functionality is fully implemented) and can poke around at dmd in gdb in the hopes of getting some useful info to the contributors (I have very little knowledge of compilers, though I have been gleaning details from running dmd in gdb. I'm not yet at the point where I can attempt my own fixes, though I hold out hope that some things will click soon and I can make a more active contribution effort).

We're willing to invest in D, in whatever way we can, and hope to someday (sooner rather than later) add ourselves to the list of D success stories.

But, our success depends on a stable, multi-platform implementation. So we are open to ways on how we might improve D more proactively. Right now we are developing on dmd git head (for the latest fixes) but would like to transition to ldc (for the optimization) as we solidify our design.

On Monday, 15 December 2014 at 20:40:29 UTC, evenex wrote:
> This is just my $0.02, not to ask for anything specific, but to add to the cross-section of perspectives on this topic, to whom it may concern:
>
> A colleague and I are writing a framework for building and managing complex simulations and chose to implement in D for the modeling power that the template system brings, which allows us to make an expressive and fairly performant API that is also flexible and easily refactored thanks to static assert and unittest...
>
> But we keep getting hamstrung by bugs; hitting compiler segfaults during template metaprogramming is a very common occurrence, and sometimes UFCS fails. We continue to make progress but lose a lot of time finding workarounds for apparently valid but noncompiling code. We are hoping that with the increased interest in D lately, the implementation will stabilize, but we are nervous about the long-term prospects.
>
> This is a risk we knowingly undertake in exchange for the aforementioned advantages. A lot of cool stuff is possible with D that we can't do in other languages but I constantly work with the fear that we'll stumble upon some compiler bug in 6 months time that we can't find a way around. (I originally tried to write this system in C++ and I dread the idea of returning to it.)
>
> One of our target use-cases is gaming, and to this end we hope that the difficulty we've had in getting D environments working in Windows will be alleviated soon so that we can confidently target that platform.
>
> As typical college students (I am a senior, partner is recent grad) we can't afford to put up bounties or contract anyone but we put up bug reports when we can (this will be easier when dub dustmite functionality is fully implemented) and can poke around at dmd in gdb in the hopes of getting some useful info to the contributors (I have very little knowledge of compilers, though I have been gleaning details from running dmd in gdb. I'm not yet at the point where I can attempt my own fixes, though I hold out hope that some things will click soon and I can make a more active contribution effort).
>
> We're willing to invest in D, in whatever way we can, and hope to someday (sooner rather than later) add ourselves to the list of D success stories.
>
> But, our success depends on a stable, multi-platform implementation. So we are open to ways on how we might improve D more proactively. Right now we are developing on dmd git head (for the latest fixes) but would like to transition to ldc (for the optimization) as we solidify our design.

Is your project open source?   If so as a student we will likely be looking for applications to the 2015 Google Summer of Code, if D is accepted as a mentoring organization.  I would need to investigate if having a student working on their existing project would be allowable, but it might be possible.  We would still have to find a mentor for you.

Alternately GSOC 2015 might be your chance to learn a bit more about compilers!

On Monday, 15 December 2014 at 20:40:29 UTC, evenex wrote:
> This is just my $0.02, not to ask for anything specific, but to add to the cross-section of perspectives on this topic, to whom it may concern:
>
> A colleague and I are writing a framework for building and managing complex simulations and chose to implement in D for the modeling power that the template system brings, which allows us to make an expressive and fairly performant API that is also flexible and easily refactored thanks to static assert and unittest...
>
> But we keep getting hamstrung by bugs; hitting compiler segfaults during template metaprogramming is a very common occurrence, and sometimes UFCS fails. We continue to make progress but lose a lot of time finding workarounds for apparently valid but noncompiling code. We are hoping that with the increased interest in D lately, the implementation will stabilize, but we are nervous about the long-term prospects.
>
> This is a risk we knowingly undertake in exchange for the aforementioned advantages. A lot of cool stuff is possible with D that we can't do in other languages but I constantly work with the fear that we'll stumble upon some compiler bug in 6 months time that we can't find a way around. (I originally tried to write this system in C++ and I dread the idea of returning to it.)

I can understand all of the above. I'm in a similar situation. Fortunately, I've always been able to find a workaround - so far.

> One of our target use-cases is gaming, and to this end we hope that the difficulty we've had in getting D environments working in Windows will be alleviated soon so that we can confidently target that platform.
>
> As typical college students (I am a senior, partner is recent grad) we can't afford to put up bounties or contract anyone but we put up bug reports when we can (this will be easier when dub dustmite functionality is fully implemented) and can poke around at dmd in gdb in the hopes of getting some useful info to the contributors (I have very little knowledge of compilers, though I have been gleaning details from running dmd in gdb. I'm not yet at the point where I can attempt my own fixes, though I hold out hope that some things will click soon and I can make a more active contribution effort).
>
> We're willing to invest in D, in whatever way we can, and hope to someday (sooner rather than later) add ourselves to the list of D success stories.
>
> But, our success depends on a stable, multi-platform implementation. So we are open to ways on how we might improve D more proactively. Right now we are developing on dmd git head (for the latest fixes) but would like to transition to ldc (for the optimization) as we solidify our design.