Why aren't you using D at work?

[Chris via Digitalmars-d]

On Friday, 29 May 2015 at 14:03:19 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 29 May 2015 at 11:29:13 UTC, Chris wrote:
>> This is very interesting. It kinda defeats the "D is too 
>> complicated" argument I often hear.
>
> I don't know what is typical, but I am dealing with Python, 
> Javascript, Dart, C++ and Objective-C for commercial use, and 
> plan on adding Swift. C++14 is by far the most taxing, due to 
> not enough rigour in the language design (complications with no 
> benefits!). Dart you can master in a week, and is more 
> productive than C++. So I have a lower threshold for adding a 
> "Dart-like" language with an IDE than a "C++-like" language for 
> commercial use. My threshold for adding Swift is very low due 
> to the perceived simplicity and decent tooling.

D is not perceived as a simple language, although it can be 
trivial to use sometimes. To simply get things done the languages 
mentioned above are certainly a good choice and if you develop 
for mobile phones, D is certainly not a good choice _at the 
moment_.

However, for a constantly growing long-term code base, D is my 
language of choice. It's clean (i.e. maintainable), flexible 
(many ways to tackle new problems), easily unit-testable and, of 
course, compiles to native machine code. It also interfaces to 
C(++) which is very important.

>>> 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.
>>
>> And if D offered various models (cf. std.allocator), would you 
>> still prefer languages with just one model for the sake of 
>> simplicity and not having to worry about which model to choose?
>
> I would prefer one clean heap-model that the compiler can 
> optimize easily + compiler backed stack allocation, and that 
> most third party libraries are written for. Almost all my 
> performance oriented allocations are on the stack or are 
> preallocated in big blocks, so I'd put more emphasis on things 
> like VLA (which is available as a C++ extension in clang/gcc).
>
> There is no way a generic solution can beat a tailored solution 
> when it comes to abstract datatypes and memory management, so 
> having lots of options in a standard library sounds useful.
>
> But interoperability matters more. Like, I am likely to use 
> Swift for ios/osx GUI, but need a companion language for the 
> core application engine. C++ is most likely today. If Rust or D 
> makes integration with Swift easy then I would consider a 
> switch. The bottom line is overall productivity, long term 
> maintenance and risk for hitting an issue that requires "ugly 
> unsupported hacks".
>
> It is much more difficult to find a place for a "middle ground" 
> solution than a very focused heavy duty solution or a very 
> light solution that is easy to get on with. I don't think 
> people look for "middle ground" solutions when the try to solve 
> a problem.

My approach has been similar. The GUI could be anything, the core 
is D. I don't want to rewrite core functionality in various 
languages, and with other languages I always hit a wall that says 
"Thus far shalt thou go and no further!"