untrusted comment: verify with st.pub
RWQTleDnDrmVqRiVPozMGUJvI8TQBLGEWOBFaMaj0qcRiPi78SoiFV0ogfdD0YdpBeDdukhkN9Yib9Y2BLWf5KhhzyFNOA0xGQM=
I read Louis Brauer's toot @
[email protected]/109922633616265585 the gist
of which is that Louis is abandoning his Common Lisp web backend for
greener pastures, citing unreliable dependency packages.
This is important. Let's continue the story.
@
[email protected] shared; yes, for a web backend golang works well.
Caveat: Golang tooling started including telemetry leading to
abandonment.
Golang's Rob Pike has written about how any code in your project is code
in your project. There is no way to not be responsible for the code of
the dependencies of your project.
The following happened a few years ago: All my city's web design
companies are Google Firebase Facebook React javascript companies.
Google Firebase is a way of using Facebook React javascript. Google
suddenly broke Google Firebase Facebook React's compatibility to
Facebook's Facebook React tooling, which the Google Firebase Facebook
React businesses had been using (Google pushed people onto a still-beta
Google Firebase Facebook React tooling product).
Which is the point. Those dependencies, and the local companies' view of
themselves not having responsibility for those dependencies was nuts.
Introducing a dependency to a project introduces responsibility for that
whole dependency that is or in the future will be touchable by your
project. If something goes wrong because of this, from the perspective
of people using your project, this is your problem (customers of those
web design companies in the example).
We still want to use dependencies - share our code with others. This is
one strategy: In order to save a headache, we choose what get called
canonical dependencies. ASDF3 for system definition in lisp. Alexandria
for filling in utilities missing from the standard (such as the
#'with-gensyms macro). Alexandria depends on a pre-existing culturally
significant package, split-sequence.
What about a high level dependency like Shinmera's tooter, the official
CL mastodon client-to-server package. Shinmera is well known. #:tooter's
dependencies are specifically the Edi Weitz collection of packages-
#:cl-ppcre fast compiled regular expressions, the #:drakma (stack) for
web requests. Edi Weitz' ecosystem is in a sense canonical. I think
continued support can be depended on in the future.
Actually, Weitz' legacy as a dependency is a bit too big for me, though
maybe that's inevitable with some of its targets. I remember not liking
#:cl+ssl when I looked at it, though that was a long time ago and might
be my failing.
There's a style of dependency whose names are prefixed with trivial-
meaning they only add one specific, tiny and well-known feature.
#:trivial-garbage adds weak pointers in line with academic publications
on that. I like this style of dependency. You have to be socially aware
of where the project fits in common lisp, you can't just trust projects
with trivial- in their name.
Another depency strategy is to accept being fast-moving. This is the
balls-to-the-wall strategy of development, which it sounds like Louis
was engaging in. ultralisp quicklisp package source. Resiliency here
means that when one of your supports breaks, you yourself are going to
compete to be the one to create its replacement; and you look forward to
this opportunity, as do your peers. It's high octane.
