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.
