move log/ to log/2022

content/log/2022/first-post-here.md

@@ -0,0 +1,7 @@
+---
+title: "First Post Here"
+date: 2022-04-11T18:16:36+03:00
+---
+
+This is the first post of the third iteration of jakstys.lt. The me-human is
+still changing, so do my public platforms.

content/log/2022/git-subtrac.md

@@ -0,0 +1,139 @@
+---
+title: "zig, git-subtrac and dependencies"
+date: 2022-04-23T05:37:51+03:00
+draft: true
+---
+
+TLDR: modern programming languages make it very easy to add many dependencies.
+That is nice for development, but a nightmare for maintenance. Unfortunately,
+zig is following suit. I wish we could accept that adding dependencies does not
+have to be trivial. If we accept that, thanks to ubiquity of git, we may have
+almost solved the dependency problem.
+
+Adding dependencies
+-------------------
+
+All of the programming languages I've used professionally whose name does not
+start with "c"[^1]  have package managers[^2], which make "dependency
+management" easy. These package managers will, as part of the project's build
+process, download and build the dependencies, making adding and using
+third-party dependencies easy.
+
+Because C/C++ still does not have a universal package manager, not adding
+external dependencies to C/C++ is the path of least resistance. Instead, it is
+common to rely on libraries already installed in the system. Because of this
+cultural difference, there is a plethora of dependency managers that will
+discover, but not install dependencies: autotools, cmake, pkg-config and
+others. As a result, C/C++ projects I've been involved usually had 0-5
+non-system dependencies, whereas non-C/C++ projects -- tens, hundreds or
+thousands[^3]. Having many system dependencies is painful for user experience,
+so (the good) C/C++ projects also avoid having too many of them.
+
+Not doing things that are easy to do requires discipline: brushing teeth,
+limiting candy intake, not adding dependencies all over the place. If it is
+easy to add dependencies and there is no discipline not doing so, the project
+will gain a lot of dependency "weight" with time.
+
+{{<img src="_cheese/2022/brick-house.jpg"
+    alt="House made out of Duplo pieces"
+    caption="Just like this brick house, \"modern\" package managers are optimized for building, not maintenance. Photo mine, house by my sons."
+    hint="photo"
+    >}}
+
+In Go and Python small number of dependencies is often a sign of care and
+quality. [mattn/go-sqlite3](https://github.com/mattn/go-sqlite3),
+[uber/zap](https://github.com/uber-go/zap),
+[apenwarr/redo](https://github.com/apenwarr/redo) and
+[django](https://djangoproject.com) are good examples. Making it easy to depend
+on external code is is convenient during development, but frees developers from
+their basic right (or obligation?) to audit understand them. And adds real
+long-term maintenance costs.
+
+The costs of just having dependencies are huge. I haven't done a survey and
+have only my experience to base this on (read: "many anecdotes of me failing to
+build stuff I wrote a decade ago"). But it is bad enough that I have a
+dependency checklist and am prepared to do grunt work to avoid or strip it.
+Here is my checklist:
+
+- Obvious: does it work at all?
+- How easy is it to build, run and run it's tests?
+- Is it well written? API surface, documentation, tests, error handling, error
+  signaling, logging, metrics (if applicable), etc.
+- It's system dependencies.
+- It's transitive dependencies.
+
+If a dependency is well written, but has more transitive dependencies than I
+need and there is no good alternative, I will fork it and remove unnecessary
+code and dependencies. My recent example is
+[sql-migrate](https://github.com/motiejus/sql-migrate).
+
+To sum up, the "modern" languages optimize for initial development experience,
+not maintenance. And as [Corbet says][linux-rust]. "We can't understand why
+Kids These Days just don't want to live that way". Kids want to build, John,
+not maintain. A 4-letter Danish corporation made a fortune by selling toys that
+do not need to be maintained: they are designed to be disassembled and built
+anew. It is very hard to change the guts of an existing structure without
+rebuilding it.
+
+If I may combine Corbet's views with mine: if we understand and audit our
+dependencies (and transitive ones), we will have less dependencies and a more
+maintainable system. Win-win.
+
+Which brings us to...
+
+Transitive dependencies and git-subtrac
+---------------------------------------
+
+[`git-subtrac`][git-subtrac] does not deal with transitive dependencies. At
+least not directly. Or I am not aware of it. Ok, I haven't tried.
+
+If we audit and thus understand our dependencies, we will be able to add
+transitive ones to our project even without support of git-subtrac. So perhaps
+git-subtrac shouldn't care?
+
+I use [`git-subtrac`][git-subtrac] for some of my projects, and am not very
+enthusiastic about Zig getting it's own package manager (can we all use
+git-subtrac and be done with it?). A few weeks ago in a park in Milan my
+conversation with [Andrew Kelley](https://andrewkelley.me/) was something like:
+
+- me: "git-subtrac yadda yadda yadda submodules but better yadda yadda yadda".
+- Andrew: "if I clone a repository that uses it with no extra parameters, will
+  it work as expected?"
+- me: "no, you have to pass `--recursive`, so git will checkout submodules...
+  even if they are already fetched."
+- Andrew: "then it's a piece-of-shit-approach."
+
+Uh, I agree. People have not grown muscle memory to clone repositories with
+`--recursive` flag and never will, so it's impossible to adopt git-subtrac
+beyond well-controlled silos. Which is why we will have a
+yet-another-programming-language-specific-package-manager, this time for zig.
+Or at least my argument for using git-subtrac stops right there.
+
+Why git-subtrac?
+----------------
+
+[`git-subtrac`][git-subtrac] is like "classic" git submodules, but all refs of
+the dependencies stay in the same repository. Wait, stop here. Repeat after me:
+_it is git submodules, but all refs stay in the same repository_. I also call
+it "good vendoring". Since all the deps are in our repo, no external force can
+make our dependency unavailable.
+
+It is, howerver, harder to *add* a dependency with submodules than with, say,
+`go get <dependency>`. Let's talk about adding dependencies.
+
+Conclusion
+----------
+
+Can git checkout local submodules when they are in the same repository, so our
+conversation of reconsidering (or not having) a zig package manager doesn't
+stop after 5 seconds?
+
+[^1]: Alphabetically: Erlang, Go, Java, Javascript, PHP, Perl, Python.
+[^2]: Usually written in the same language. Zoo of package managers (sometimes
+  a couple of popular ones for the same programming language) is a can of worms
+  in an on itself worth another blog post.
+[^3]: `go.sum` of a project I am currently involved clocks around 6k lines.
+  This is quite a lot for Go, but still peanuts to Node.js.
+
+[git-subtrac]: https://github.com/apenwarr/git-subtrac/
+[linux-rust]: https://lwn.net/SubscriberLink/889924/a733d6630e3b5115/