untrusted comment: verify with st.pub
RWQTleDnDrmVqRiVPozMGUJvI8TQBLGEWOBFaMaj0qcRiPi78SoiFV0ogfdD0YdpBeDdukhkN9Yib9Y2BLWf5KhhzyFNOA0xGQM=
I read Louis Brauer's toot @louis@emacs.ch/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.

@galdor@emacs.ch 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.