Permalink
Reply
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.
