S3 is defacto proprietary protocol subject to AWS whims, such as recent v4 update of signing algorithm.

Docker, while not proprietary, still subject to moving fast and breaking things, which was amply criticised here on HN.

Common Lisp should stay a refuge from all the rug pulling around. While it's true that quicklisp is far from bedrock, adding volatile APIs into the mix won't help.

From my experience, Docker helps quite a bit with CL stuff in many cases. When you use some shared libs via CFFI, things can get fragile quick, start depending on a particular shared library version on the host system etc. So your app, for instance, works fine on Debian jessie, then you have to upgrade your host system to stretch and oops, it broke here and there. You update your quicklisp dist to fix shared lib incompatibility problem and oops again, you need a week to fix stuff that broke (this reflects some problems with CL library management, too), but you need to have your app up and running on the new system yesterday. If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example.

Right, CFFI is another can of worms. It is sometimes questionable whether the time saved by reusing C code isn't lost by debugging and integration issues. For example I ended up avoiding cl-async (a wrapper over a C library) due to these.

In my mind reimplementing in CL is better bet than pulling Docker.

Well, I did write quite a bit of CL code for money, but it's hard to get paid for reimplementing every library that one may need in CL ;(

I have not meant it in such extreme way at all :(

Just this: if something interferes badly with a basic CL feature such as SLIME (cl-async does), toss it.

cl-async works pretty well with SLIME if you use its SLIME REPL integration feature that I contributed several years ago. https://github.com/orthecreedence/cl-async/blob/master/src/r...

It basically starts an event loop in a separate thread and then wraps all of the SLIME's evals so they're executed from within that event loop.

> I ended up avoiding cl-async

What do you use instead?

I reimplemented the parts I needed using threads+usockets. There's no fundamental reason it can't be built directly on OS async interfaces, even without threading, instead of C library.

> If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example.

That is perfect match for guix channels too.

What I do is maintain a repository of package definitions (that possibly inherit from guix master package definitions) and only change a few hashes here and there when I need.