Why aren't you using D at work?
Chris via Digitalmars-d
digitalmars-d at puremagic.com
Fri May 29 07:22:53 PDT 2015
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,
> 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
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!"
More information about the Digitalmars-d