Why aren't you using D at work?

[via Digitalmars-d]

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.

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