• D.B. (150/150) Dec 23 2021 Let me just say first of all this post is not meant to be
• rikki cattermole (13/13) Dec 23 2021 Your use case is highly specific, and incredibly rare (for us anyway).
• max haughton (10/20) Dec 23 2021 Did you ask for help during this process? If not, did you use the
• John Colvin (12/13) Dec 23 2021 I am sympathetic to your goals, for sure. Without going in to the
• zjh (2/2) Dec 23 2021 On Thursday, 23 December 2021 at 18:06:35 UTC, D.B. wrote:
• Dr Machine Code (4/14) Dec 27 2021 I'm really sorry about your experience but since it's too
• forkit (7/14) Dec 28 2021 your 'expectations' need to take into account the model in which

D.B. <dave allspammersmustdie.grow.game> writes:

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 
junk.)

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 
weekly basis.

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 
particular order:

* 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, 
apparently.

* 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.

rikki cattermole <rikki cattermole.co.nz> writes:

Your use case is highly specific, and incredibly rare (for us anyway).

So dmd did use to be make based for building, this isn't the best 
solution especially when we now need to bootstrap as we are self hosting 
now.

None of that matters today however, due to the fact that dmd is now 
written in D. You have to already have a working D compiler to build it. 
Boot strapping allows us to get from a c++ version to the current D one. 
That is a key feature of the build.d file.

But in saying all this, you probably just want to use gdc. Its part of 
gcc, so if you have got gcc working, gdc shouldn't be too big of a 
stretch to add to your list.

Once you have the compiler building, then its just a matter of getting 
the runtime + standard library working with musl if its not already.

max haughton <maxhaton gmail.com> writes:

On Thursday, 23 December 2021 at 18:06:35 UTC, D.B. wrote:
 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.

 [...]

Did you ask for help during this process? If not, did you use the 
automatic bootstrapping flag in build process. Which zip file are 
you actually referring to. People bootstrap D on relatively wacky 
platforms fairly regularly so if you didn't ask for help you 
should ask now.

Also you ask for longer documentation - there are several books 
about D, did you try them? If not then there's what you're 
looking for. Ali Cehreli wrote a book teaching D from scratch, 
it's very good.

John Colvin <john.loughran.colvin gmail.com> writes:

On Thursday, 23 December 2021 at 18:06:35 UTC, D.B. wrote:
 [snip]

I am sympathetic to your goals, for sure. Without going in to the 
specific problems you are having, I will say that normally the 
way things are changed/build is that a very competent and 
motivated person with specific needs/experience does the work. 
The “problem with your problem” here is that everyone else 
involved is routinely (often extremely) online, *including all 
the people who could help you make the offline version of things 
work well*. Someone has to bridge the gap and while it’s nice to 
imagine that it will be someone with all the (in)conveniences of 
the modern all-day,all-night internet, I wouldn’t bet on it given 
other constraints.

zjh <fqbqrr 163.com> writes:

On Thursday, 23 December 2021 at 18:06:35 UTC, D.B. wrote:

I use windows ,no such things.

Dr Machine Code <jckj33 gmail.com> writes:

On Thursday, 23 December 2021 at 18:06:35 UTC, D.B. wrote:
 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'm really sorry about your experience but since it's too 
specific, it's hard to have a group of people working on that. It 
would work if you more like-minded people to put time into that.

forkit <forkit gmail.com> writes:

On Thursday, 23 December 2021 at 18:06:35 UTC, D.B. wrote:
 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.
 ...
 .....

your 'expectations' need to take into account the model in which 
D is (and has been) developed. When you consider this, you should 
be thankful that D even exists ;-)

on the upside (to your downside).. it's all freely available, 
open source..

you wanna create a betterD... go for it.