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