New to D. First impression not good.
dave at allspammersmustdie.grow.game
Thu Dec 23 18:06:35 UTC 2021
Let me just say first of all this post is not meant to be
provocative, and also, I haven't even got a chance to use the
language yet. That's what's so frustrating. It seems like a good,
well designed language, but frankly the install/bootstrapping
process is not well designed. I'm frustrated and want to vent
right now before going further. Actually, I'd rather to see these
problems fixed before proceeding. Show me that you really care
about doing things Right.
I have created my own Linux distro from scratch. It uses Musl
libc and cross compiles to i686, x86-64, arm, and aarch64. So
while I'm a 'newbie', I'm not an idiot. There is one rather
simple script which builds the whole system; over a thousand
packages. Exactly one environment variable has to be set, with
others optional as needed, and all of it well explained with
examples, right there at the beginning of the script. Of course,
the main script has to chain out to other individual scripts to
install each 'stage' and for each package in that stage, but it's
all simple, straightforward, and well commented. As far as I'm
concerned, this is the gold standard of "how it should be done."
In the process of creating this distro with its wide variety of
packages, I have seen every kind of build system there is. Most
fall into a few broad categories, and the majority of the time,
building and installing is simple, using standard configure/make,
cmake/make, meson/ninja, or other well known, standard idioms.
(There are however a surprising number of packages which manage
to even screw this up, requiring patches to fix their broken
Then there's people like Jorge Schilling for example who
completely invent their own ecosystem which is compatible with
nothing, which can't/shouldn't even be installed in the /usr tree
as it will break the system, to name one particularly egregious
example of doing things in a totally wrong way. As a distro
maintainer and power user, I strongly prefer packages which
conform to standard idioms and do not create their own unique and
different ecosystem that is incompatible with everything else.
My workflow is also different than most in that I don't have
internet at home, where I do my computing. There are no good
options here and they are not worth paying for. Frankly, the
state of computing with its total lack of privacy and security is
such that I'm happy to do all my computing offline, and only
drive into town to do file transfer, email, etc in batches, on a
Sadly, and infuriatingly, these days computing has been wrecked
by the foolish assumption that everyone everywhere has high speed
internet available 24/7. So we have developers today who think
nothing of just reaching out to the internet whenever they feel
like it, even going so far as embedding package downloads in the
middle of major compile processes with no option at all to
manually download anything. (Which is why I want nothing to do
with the Haiku OS, to name the worst example I've seen.)
Developers today also have the infuriating habit of providing
absolutely no documentation at all with their shitware, instead
preferring to just direct me to some web page somewhere instead.
Often launching a web browser without warning. This is a product
of laziness and apathy.
(On the same note, I've had to patch dozens of packages to remove
their auto update check garbage. It's quite offensive how
ubiquitous is this idea of just reaching out to remote websites
on a whim, when such behaviour is not desired.)
Another quite aggravating misfeature of many software packages is
the spreading out of their component parts into multiple
archives, which sometimes aren't even located in the same place,
thus ensuring one can't just download one or files and be assured
one has the whole thing, but instead have to make multiple round
trips to the network, and be surprised by dependencies which
weren't even mentioned on the download site.
Now before anyone attempts to argue that it's sooooo weeeeiird
that someone doesn't have high speed internet or even internet at
all on their development computer, let me assure you it's far
more common than you think in certain circles, and furthermore,
it's only a matter of time before you're all in the same boat
yourself. When the internet goes down hard--and it will--people
like me will still be computing the same as before, while people
who have built up an absolute dependency of always-on internet
access will be in a similar situation to the heroin junkie whose
supplier is dried up. Which group would you rather be in?
Now looking at the D bootstrap process, I'm completely
disappointed. All of these things I pointed out above, D is
doing. I downloaded the 'complete' D compiler package, intending
to bootstrap the compiler, and found serious problems. In no
* The package contains built binaries and libraries, but no
indication of what to do with them, particularly in regards to
bootstrapping the included source code. There is no documentation
or instructions included, other than a very brief README, which
is trying to send me to an FTP site to download a linker. There
is an extra file dmf.conf, with no indication of what this is or
where it should go. All documentation is somewhere online,
* Everything about being sent to an FTP site to download a linker
is wrong. First off, the geniuses at Google have decided to
deprecate FTP, so I can't browse to it, just use an FTP client
(pain in the ass) or wget. The problem then becomes, why am I
being directed to a completely unversioned file? Why is it a ZIP
file, on a Linux system? Why can't I just use the system linker?
Why isn't the linker already included in this 'complete' binary
release package? And most importantly, why wasn't I told about
this apparent hard requirement on the download page, with a link
provided right then and there, preferably to an HTTP directory
with multiple versions available in standard .tar.* formats?
* There are no instructions on how to properly install this
binary compiler and use it to build itself plus phobos etc.
There's a build.d which I couldn't make work no matter how I
tried invoking it. The compiler quickly failed with a million
missing symbol errors. Presumably due to the missing linker. I
have no idea, and the output tells me nothing. Also the dmd.conf
seems to play a role somehow, but again, no instructions. Just a
link to a web page, which is unacceptable. Presumably I will make
another trip out to the internet only to find yet another
critical package is missing, requiring yet another round trip.
* This isn't even getting into D's own build system, which surely
has its own quirks and oddities and incompatibilities.
I recommend completely reworking how D is built and distributed
in order to fix this situation.
First off, the compiler binaries/libraries should be distributed
in their own separate package, which could possibly come in two
forms: a shell archive which makes the install process completely
automatic, and/or an archive with a basic installer script or
clear instructions on how to properly install the compiler. If
the linker is really required, that should come with the package.
The source code should be separated into its own archive,
including linker source code also if needed, and it should come
with a standard Makefile, or ideally, cmake based build system.
Yes, really, even if it's only a wrapper over build.d, which
checks for dependencies and tells me clearly that everything is
correct before proceeding. I don't like obscure, undocumented
build systems that fail with bizarre errors, requiring reverse
engineering to figure out.
On another note, I do like that sample D code is included in the
package, but this needs to be greatly expanded. Documentation and
examples for D in general seem to be very poor. One site seemed
to have plenty of information, but no download option for offline
viewing. Another site wanted me to pay to access their
information. No thanks. How about a 100+ page PDF with a complete
tutorial of all language features from simple to more complex,
ideally linked for download right next to the compiler binary and
source packages? Put it all right there in one spot, please. Make
it as easy as possible.
Unless and until these issues are addressed, I am sorry to say
I'm going to have to abandon D for the time being. I want to try
the language, but not if it's too annoying and cumbersome to even
get started, and particularly if always on internet access is a
hard requirement to get anything done with it.
Please remember that while you have been using and apparently
loving this language for some time (with it even being described
as a 'secret weapon' by some), I have no such experience, and
learning and getting into a new language is a major use of time
which could possibly be wasted, if this install process is
foreshadowing other design flaws that will only become apparent
later on down the road. Thanks for listening.
More information about the Digitalmars-d