On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu wrote:
> On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote:
>> * Forceinline.
>
> Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei

Yes, likely, unlikely, forceinline, and noinline are important tools.
You should already be able to use PGO which gives the compiler real statistics about your program and is good for a 5-10% speedup.
https://github.com/D-Programming-Language/dmd/pull/4651

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> I expect I'm not alone. Please share the absolute blockers preventing
> you from adopting D in your offices. I wonder if there will be common
> themes emerge?

- Quality of ecosystem. It's relatively simple to run into an issue, that requires one to be a D expert to resolve (codegen bugs, ICEs, CTFE bugs, undecipherable error messages). Fairly problematic for learning the language, especially for people without C++ background.

- Lack of libraries. We're missing too many components and the fact that I'd have to write 3 libraries to realize a tiny project makes it particularly hard to get a foot in the door.

- Learning material. To much knowledge about D is implicitly shared among contributors and heavy users (e.g. local imports should be selective, or they might shadow symbols) making it harder to learn the language. Outdated information on dlang.org doesn't help either.

On Thursday, 28 May 2015 at 20:22:44 UTC, rumbu wrote:
> - lack of a decimal data type - you cannot perform monetary calculation using floating point.

http://dlang.org/phobos/std_bigint.html?

> - lack of a chinese or japanese calendar in the std.datetime module;
> - missing of overflow checks for integral data types;

http://dlang.org/phobos/core_checkedint.html

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> I expect I'm not alone. Please share the absolute blockers preventing
> you from adopting D in your offices. I wonder if there will be common
> themes emerge?

If you're interested in enterprise point of view, our ecosystem is build around .net technologies, it gets the job done, so it's usually hard to come up with a case for D. There is a small utility, which updates database in a multithreaded fashion and doesn't share code with the rest of the project, but it needs database connectivity for mssql and oracle and again D can't show any advantage in such use case.

On Friday, 29 May 2015 at 08:57:46 UTC, Martin Nowak wrote:
> On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu wrote:
>> On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote:
>>> * Forceinline.
>>
>> Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei
>
> Yes, likely, unlikely, forceinline, and noinline are important tools.
> You should already be able to use PGO which gives the compiler real statistics about your program and is good for a 5-10% speedup.
> https://github.com/D-Programming-Language/dmd/pull/4651

Walter said likely/unlikely won't be implemented as the compiler already assumes the first condition is the more likely one the last time this was brought up.
I'm not sure if this is still true.

On Friday, 29 May 2015 at 09:33:25 UTC, Kagamin wrote:
> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>> I expect I'm not alone. Please share the absolute blockers preventing
>> you from adopting D in your offices. I wonder if there will be common
>> themes emerge?
>
> If you're interested in enterprise point of view, our ecosystem is build around .net technologies, it gets the job done, so it's usually hard to come up with a case for D. There is a small utility, which updates database in a multithreaded fashion and doesn't share code with the rest of the project, but it needs database connectivity for mssql and oracle and again D can't show any advantage in such use case.

Same here.

Our customers live in Java and .NET world. They also tend to choose the technology stack themselves.

C++ only appears into the scene when there is the need for some OS integration or performance boost. So just as JNI, P/Invoke, COM component.

Also there are native compilers for both eco-systems around the corner. .NET Native on one side and the AOT support is being discussed for Java 10 (ignoring the commercial options).

For the customers doing mobile projects, we tend to go with a mix of platform SDKs and some web help.

Overall, for the amount of C++ code that gets written, D would hardly make any difference and cannot compete with the eco-systems being used from business case point of view.

On Friday, 29 May 2015 at 09:50:29 UTC, weaselcat wrote:
> Walter said likely/unlikely won't be implemented as the compiler already assumes the first condition is the more likely one the last time this was brought up.

That is not what he said http://forum.dlang.org/post/m8739b$an$1@digitalmars.com.

On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
> The trick is getting something (anything) to shift to D in the office,
> giving other programmers some exposure, and give us a context to
> experiment with D in application to our particular workload; that is,
> realtime processing and rendering of geospatial data, an ideal
> workload for D in my mind! http://udserver.euclideon.com/demo (demo is
> NaCl + Emscripten, we'd love to have written it in D!)

Are you working with Euclideon / Bruce Dell? Sounds fun!

I am not using D for anything serious:

1. Partially because C++/clang is more mature and does a better job for real time audio. I am using my own libraries that provides the features D has, but C++ lacks.

2. Since not using C++ at all is not an option, I've had to spend more time than I've enjoyed figuring out how to do C++14 style meta programming, which is annoying and somewhat time consuming. D is better, in some areas, but lacking in others. So metaprograming is not a good enough reason to switch.

3. D's memory model is up in the blue, C++ has locked down on one model, Rust on another. I am currently starting to think that Rust is a more likely option than D given the direction D might be taking towards reference counting etc. But I am not using Rust either… just watching how it develops.

On Thursday, 28 May 2015 at 17:22:21 UTC, Andrei Alexandrescu wrote:
> On 5/28/15 8:38 AM, Manu via Digitalmars-d wrote:
>> * Forceinline.
>
> Thanks for initiating this! The lack of a means to force inlining has been unpleasant at Facebook as well. It would be great if we got this (and of course other items on the list) rolling. -- Andrei

I understand the position you and Walter are in that you are nagged regularly for wrong-headed or pet features but I do think a lesson needs to be taken from forceinline that standard features like this need to go in. Poor Manu has been beating that drum for so long. If multiple members of the community keep coming back to a thing over time then it needs to be seriously reexamined and not enter the state I see in some communities where it because almost a religious commandment as the community is sick of discussing it and there has been a command from on high that it will not be that way. It's very much like generics in Go. The problem is that people forget what the arguments actually were and take away a possibly wrongheaded sense of conclusion which fossilizes. Perhaps the issue re-openner should be responsible for a detailed summary of the arguments previously given before and against and any new additions rather than people making references to disparate and sometimes private threads.

On Friday, 29 May 2015 at 10:05:08 UTC, Paulo  Pinto wrote:
> On Friday, 29 May 2015 at 09:33:25 UTC, Kagamin wrote:
>> On Thursday, 28 May 2015 at 14:38:51 UTC, Manu wrote:
>>> I expect I'm not alone. Please share the absolute blockers preventing
>>> you from adopting D in your offices. I wonder if there will be common
>>> themes emerge?
>>
>> If you're interested in enterprise point of view, our ecosystem is build around .net technologies, it gets the job done, so it's usually hard to come up with a case for D. There is a small utility, which updates database in a multithreaded fashion and doesn't share code with the rest of the project, but it needs database connectivity for mssql and oracle and again D can't show any advantage in such use case.
>
> Same here.
>
> Our customers live in Java and .NET world. They also tend to choose the technology stack themselves.
>
> C++ only appears into the scene when there is the need for some OS integration or performance boost. So just as JNI, P/Invoke, COM component.
>
> Also there are native compilers for both eco-systems around the corner. .NET Native on one side and the AOT support is being discussed for Java 10 (ignoring the commercial options).
>
> For the customers doing mobile projects, we tend to go with a mix of platform SDKs and some web help.
>
> Overall, for the amount of C++ code that gets written, D would hardly make any difference and cannot compete with the eco-systems being used from business case point of view.

I'm using D at work successfully. However, what is lacking that makes it hard to convince others:

1. [medium priority]
No standard GUI ("Look Ma, there's a button that says 'Hello, world!', if I press it!"). You can work around that, because you can still call D from any GUI either as an executable, a socket or interface to D (via C). Still, people love GUIs. I hope dlangui can help here.

2. [high priority]
Uncertainty regarding ARM (iOS/Android). Deal breaker, show stopper. Was worrying a few years ago, but is just bad now in 2015.

3. [constant priority]
Learning resources, learning curve. As mentioned in a comment above: you have to know D well to be able to make sense of error messages etc. You need to know D "low-level" or D's internals in order to take full advantage of it. A lot of concepts are unfamiliar to people and/or not yet common ground (ranges, templates, component programming), especially as inbuilt features. The other day I needed startswith and ctypes in Python and immediately got this:

https://docs.python.org/2/library/stdtypes.html
https://docs.python.org/2/library/ctypes.html

For D I get:

==> http://dlang.org/phobos/std_string.html
==> http://dlang.org/phobos/std_algorithm.html#startsWith
==> http://dlang.org/phobos/std_algorithm_searching.html#.startsWith

uint startsWith(alias pred = "a == b", Range, Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range && Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart, withOneOfThese[1..$])) : uint));
bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, R2 withThis) if (isInputRange!R1 && isInputRange!R2 && is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool));
bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E withThis) if (isInputRange!R && is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool));

WTF? :-)

I know, we all know that, but still it puts people off, a simple psychological issue. D smells of elitism and hackeritis. Python and Java are more like "Hey, I can do it too. Look Ma, it prints 'Hello, world!'!!!" In other words, it doesn't make people feel good about themselves, there's no immediate reward. This is purely a marketing issue and has nothing to do with the language itself. But even if people are free to chose a language, they shy away from D.

And since we're talking about psychology, I think D is a language you only come to appreciate after years of programming in other languages. People won't adopt it as long as they feel comfortable - or secure - in other languages, as long as they don't see an immediate benefit in using D. I'm not sure if there's anything the D community can do about this except for keeping on keeping on.