I like dlang but i don't like dub

Guillaume Piolat first.last at gmail.com
Sat Mar 19 20:32:50 UTC 2022


On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote:
> Dlang includes some good ideas.
> But dub pulls in so much stuff. Too much for me.
> I like things which are clean,lean,little,small.
> But when i use dub it links with so many libraries.
> Are they really needed ?
> And how do you compare to pythons pip.
> Feel free to elaborate.

DUB changed my programming practice.

To understand why DUB is needed I think it's helpful to see the 
full picture, at the level of your total work, in particular 
recurring costs.


### An example

My small software shop operation (sorry) is built on DUB and if I 
analyze my own package usage, there are 4 broad categories:

  - Set A. Proprietary Code => **8 packages, 30.4** kloc

  - Set B. Open source, that I wrote, maintain, and evolve => **33 
packages, 88.6** kloc

  - Set C. Open source, that I maintain minimally, write it in 
part only => **5 packages, 59.1** kloc

  - Set D. Foreign packages (not maintaining it, nor wrote it. 
Stuff like arsd) => **14 package, 45.9** kloc

=> Total = **224 kloc**, only counting non-whitespace lines here.

This is only the code that needs to be kept alive and maintained. 
Obviously code that is more R&D and/or temporary bear no 
recurring cost.



Visually:

     Set A: ooo         30.4 (proprietary)
     Set B: ooooooooo   88.6 (open-source)
     Set C: oooooo      59.1 (open-source)
     Set D: oooo        45.9 (open-source)
     --------------------------------------
     Total: oooooooooooooooooooooo





### What is the cost of maintaining all that?

At a very minimum, all code in A + B + C + D needs to build with 
the D compiler since the business use it, and build at all times.

Maintaining the "it builds" invariant takes a fixed cost m(A) + 
m(B) + m(C) + m(D).

Here m(D) is beared by someone else.
As B and C are open-source and maintained by me, the cost of 
building B and C for someone else is zero, that's why ecosystem 
is so important for language, as a recurrent expense removal. And 
indeed, open-source ecosystem is probably the main driver of 
language adoption, as a pure capital gain.

Now consider the cost of evolving and bug fixing instead of just 
building.
=> This is about the same reasoning, with perhaps bug costs being 
less transferrable. Reuse delivers handsomely, and is cited by 
the Economics of Software Quality as one of the best driver for 
increased quality [1]. Code you don't control, but trust, is a 
driver for increased quality (and as the book demonstrate: 
lowered cost/defect/litigations).


### Now let's pretend DUB doesn't exist

     For maintaining the invariant "it builds with latest 
compiler", you'd have to pay:
        m(A) + m(B) + m(C) but then do another important task:

        => Copy each new updated source in dependent projects.

Unfortunately this isn't trivial at all, that code is now 
duplicated in several place.

Realistically you will do this on an as-needed basis. And then 
other people can rely on none of your code (it doesn't build, 
statistically) and then much fewer ecosystem becomes possible 
(because nothing builds and older version of files are 
everywhere).

Without using DUB, you can't have a large set of code that 
maintain this or that invariant, and will have to rely to an 
attentional model where only the last thing you worked on is 
up-to-date.

DUB also make it easy to stuff your code into the B and C 
categories which provides value for everyone. With DUB you won't 
have say VisualD projects because the cost of maintaining the 
invariant "has a working VisualD project" would be too high, but 
with DUB because it's declarative it's almost free.


[1] "The Economics of Software Quality" - Jones, Bonsignour, 
Subramanyam



More information about the Digitalmars-d-learn mailing list