What Julia Does Right

[Greggor]

On Saturday, 10 December 2022 at 14:24:53 UTC, max haughton wrote:
> On Saturday, 10 December 2022 at 05:53:37 UTC, Greggor wrote:
>> On Friday, 9 December 2022 at 19:07:21 UTC, Walter Bright 
>> wrote:
>>> [...]
>>
>> I would love that, I usually only read the forums & lurk, I 
>> made an account just to say this!
>>
>> In my case, I don't use dub, or any other package manager, I 
>> am a strong believer of your project should build without a 
>> internet connection. In a lot of my project what I do is have 
>> all my dependencies in tar files & the build script unpacks 
>> them and then builds them.
>>
>> It would be lovely if I could skip the unpacking and directly 
>> feed them into dmd.
>>
>> Not only that, this could also be an awesome way of easing 
>> distributing programs via src.
>>
>> I would love it if I could do something like `dmd 
>> myproject.tar.xz -of=myproject`
>
> If you already have the dependencies then it does build without 
> an internet connection.
>
> You can also use git submodules with dub if needed.

I'm not using git for version control, I'm using fossil so I'm 
not sure if this is applicable to me.

Its not just about building without an internet connection. It's 
more of a measuring stick I use. There are several reasons I do 
it, mainly its "trauma" from the JS/NPM ecosystem.

the two stories I'm sharing may not seem relevant, but they are 
to the point I'm making.
Maybe I'm a goof & live in a bubble, but I'd like to argue that D 
currently has a better dependence experience then most ""nicer"" 
systems based on some anecdotal evidence :^)

JS:
>My experience with the JS ecosystem especially with node.js is 
>that anything I have written or used that relied on NPM packages 
>if unmaintained for little while will stop working or gain odd 
>bugs for no good reason. At one point I had the freedom to 
>decided to do an experiment while working on a personal project 
>in JS/node where I decided to not use NPM and minimized my 
>dependency use & it changed my perspective on JS, the language 
>is fine, its the tooling, culture and ecosystem around it that 
>make it less so.
>
>Eventually I wrote a single file library that held a lot of 
>functions id reuse, and whats funny about this, I did what some 
>C devs do where I've created the "single header" library but in 
>the context of JS.

Python:
>Please understand that I am not a Python programmer, so may have 
>went at this the wrong way, but I do have a very negative 
>experience with python as a user and I feel that its still 
>important to mention.
>
>About two months ago I set up on my machine a distribution of 
>Stable Diffusion (an image gen AI, it's cool, look it up) and 
>every step of the way it was a horrid experience. First I tried 
>following the instructions provided by the project, they used a 
>package manager called Anaconda, it took over 10 minutes for it 
>to "resolve" and even then it failed to figure it out.
>After throwing away an hour of my life, I decided to do it my 
>self, so I figured out the packages I needed and installed them 
>via pip, I even thought I was being a smart cookie and used 
>something called virtual environments, and yes it did work well 
>until my distribution updated the python version and everything 
>exploded.
>I found out that the python ecosystem uses a lot of native C/C++ 
>libs and that a lot of python libraries are wrappers for them, 
>this creates a lot of "fun" when python updates.
>
>The virtual environment in python does not include a copy of the 
>python install at the time it was created and instead symlink it 
>:/, so its not actually isolated, so its just a crutch for pip 
>because python like a lot of languages do this horrid practice 
>of installing a dependence globally (or user wide). After more 
>hair loss I gave up on updating the deps, nothing seemed to work 
>and I have never written any python so I am not the person to 
>fix it, so what I ended up doing was building python 3.10 from 
>src and created a install just for this program and I changed 
>the symlink in the python env to point to it. Whats even more 
>sad, is that I found out you can't move a python environment 
>after you make it, when building python I found out you have to 
>hard code a path of where the interpreter lives, what twisted 
>mind thought this was a good idea.
>
>I wish the people doing AI picked a better language, I do not 
>understand how they reproduce anything, but I guess they are 
>smarter then I am, so maybe I'm just too dumb for python.

Dlang:
>Looking at my currently open D project, I have a couple of 
>dependencies and all of them don't have any sub dependencies, 
>that's Awesome!
>When DMD updates on my system, most things still work, at worst 
>I get a deprecation message in my build log and I investigate 
>it, the upgrade tends to be very simple, that is Awesome!
>Unlike my C++ experience, most of the time Phobos has what I 
>need & there is zero reason to reach for some 3rd party nonsense.
>When I do use a external dependency they tend to be of good 
>quality, most don't pull in a ton of sub dependencies or have 
>complicated build steps. In most cases I can just take a DUB 
>package and just add the src to my src tree and call it a day.

My goal here is not to appear like a luddite or to tell others to 
be ones, I think having nice tooling is a good goal, I'd love to 
have a good package manager for D with a quality ecosystem.

Here is how I would go about this:
	* A dependency should always be just a tar/zip file with src 
code in it.
	* The dependency (tar/zip)s should always be stored in the 
project directory & not in some system or user folder.
	* No use of symlinks
	* To help discourage NPM insanity, Build in a ""Bloat"" 
measuring tool, how many total dependencies are you using? how 
many KLOC is it?
	* https://code.dlang.org should have a link for the manual 
direct download for the src zip for all versions.

	Github, Gitea instances & Fossil all have a way of providing a 
zip file for releases, src zips are already a near universal 
method of publishing code. So this theoretical package manager 
can be really fast and light, its basically an over gloried text 
search & download tool.