On Tuesday, 25 February 2014 at 11:22:23 UTC, bearophile wrote:
An interesting comment from Reddit:
klusark>I've been trying to build this for the past hour. It
requires folly. folly requires some "double-conversion"
library, but you can't use the default version, you have to
build it with scripts from folly's source. After I finally get
folly to get past configure stage I get some random python
error in one of the build scripts. I just gave up at this
point. I'm sure I could get it working, but the time isn't
It's kind of strange (to say the least) that a D project depends
on folly and gtest - the C++ libraries. I understand that flint
is not purely a D project. It also builds the C++ binary and
library which depends on this stuff.
But I find it important to separate the 2. And the D version
should be made as easy to setup as possible. That is - no friggin
autotools, makefiles and folly/boost/gtest dependencies.
I honestly think that this stuff stands in the way of the D's
adoption big time. And this flint project should really be
separated into C++ and D part. With D part using unittests,
phobos and dub. So using it would be as simple as "dub build" and
The difference would be even more noticeable with a neighbor C++
project requiring all that autotools nonsense.
Being a C++ developer for a decade now, personally, I can handle
the D adoption curve since in its current state it's not worse
than C++'s anyway. But every time I feel really awkward
recommending D to someone else. Since I know they will encounter
many problems which require arcane (to newcomer's mind) knowledge.
Maybe another valuable example would be a "go fix" alternative.
After every release I hear the voices "It broke every line of my
code", "This release is a behemoth", "D was never and will never
be stable", etc. And I really think that if it could be handled
by "dub fix" - nobody would ever complain.
At DConf 2013 Andrei told to that question something like - "What
do you actually want? A bash script in the error message to fix
that for a whole project? Well, I guess this could be done."
So, to summarize, I guess my point is, that today's tools work so
smooth and with such low entering cost, that an
old-dog-C++-programmer considers it magic and doesn't really
value it accordingly. And since the D crowd is mostly the
old-dog-C++-programmers crowd - this aspect is really
"underlooked". But the (sad or great or mere) fact is that
today's students are not old-dog-C++-programmers and they have
really hard time using D today. So hard, that they would actually
rather use Python or Go (oh, my) or Haskell (sic!) instead of D
in their work.